@@ -30,6 +30,25 @@ With @IS_AUTHENTICATED_FULLY@ you can implement a security scheme whereby users
For more information on @IS_AUTHENTICATED_FULLY@, @IS_AUTHENTICATED_REMEMBERED@, and @IS_AUTHENTICATED_ANONYMOUSLY@, see the Javadoc for [AuthenticatedVoter|http://static.springsource.org/spring-security/site/docs/3.0.x/apidocs/org/springframework/security/access/vote/AuthenticatedVoter.html]
+The plugin isn't compatible with Grails @<g:actionSubmit>@ tags. These are used in the autogenerated GSPs that are created for you, and they enable having multiple submit buttons, each with its own action, inside a single form. The problem from the security perspective is that the form posts to the default action of the controller, and Grails figures out the handler action to use based on the @action@ attribute of the @actionSubmit@ tag. So for example you can guard the @/person/delete@ with a restrictive role, but given this typical edit form:
+ <g:actionSubmit class="save" action="update"
+ value='Update' />
+ <g:actionSubmit class="delete" action="delete"
+ value="'Delete' />
+both actions will be allowed if the user has permission to access the @/person/index@ url, which would often be the case.
+The workaround is to create separate forms without using @actionSubmit@ and explicitly set the @action@ on the @<g:form>@ tags, which will result in form submissions to the expected urls and properly guarded urls.
h4. Comparing the Approaches
Each approach has its advantages and disadvantages. Annotations and the @Config.groovy@ Map are less flexible because they are configured once in the code and you can update them only by restarting the application (in prod mode anyway). In practice this limitation is minor, because security mappings for most applications are unlikely to change at runtime.