[ 
https://issues.apache.org/jira/browse/CLK-406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12699359#action_12699359
 ] 

Joseph Schmidt commented on CLK-406:
------------------------------------

> @Joseph, can you expand on the onSecurityCheck usage? 
The first version described by Adrian is internal to Menu, so it was not 
supposed to be used somewhere else.
The version proposed by Malcolm however, being external, could be used in 
onSecurityCheck .
See the Security example:
org/apache/click/examples/page/security/Secure.java
the check:
if (getContext().hasSessionAttribute("user")) {...}
shold be extended with && hasAccess() too.

> what are the advantages? 
Roles that are enforced upon menu items (that point to pages), should also act 
upon the pages when called directly.
For most webapplications that would be more than enough, and menu.xml would the 
the single place of this role definition.

Of course, there are the other solutions too (container, acegi, jsecurity, 
etc.), but this simple one is quite good and much more simple than all the 
others - it's also portable.

Joseph.


> Menu improvements - plug-able role checking.
> --------------------------------------------
>
>                 Key: CLK-406
>                 URL: https://issues.apache.org/jira/browse/CLK-406
>             Project: Click
>          Issue Type: Improvement
>          Components: extras
>            Reporter: Demetrios Kyriakis
>
> Please improve the Menu Control, by allowing the user to have a plug-able 
> role cheking for the menu items.
> Right now the Menu Control is using HttpRequest#isUserInRole(String role), 
> but most webapplications
> don't use this strategy for user/roles management, so this method returns 
> false for all those cases :(.
> This is very limiting, making the existing Menu Control useless for most user 
> applications, thus forcing the users
> to make their own menu controls (or the hack the original one). 
> Please allow to set a different method for this operation by the user (if no 
> other is used, of course, the default one - mentioned above - would be used 
> as before - so 100% backwards compatible).
> Thank you,
> Demetrios.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Reply via email to