Re: [Wicket-user] Wicket Security Configuration Question
Thanks, Craig I've updated the getting started to include the example for the default mode, which is what most likely you will be using. I am sorry to say that as of yet i do not have an ETA for the examples but i will post it on the mailing list when i have them ready. Maurice On 6/7/07, craigdd <[EMAIL PROTECTED]> wrote: > > This original post was under wicket stuff users list and I've reposted it > hear for more visibility, as requested by Martijn. The following is the > response that I got from Maurice. > > Hi, > > what i mean is this: By default SecurePageLink (and all other links > with the same securitycheck) checks for an enable action on the page > the link points to. This check occurs both in the render (where is > decided if the link should be clickable) and in the onclick (just to > check if nobody spoofed an url to trigger a link click where it is not > allowed). > > Maybe an example will make things more clear (note to self to update > the getting started) > HomePage contains a SecurePageLink to PageA. > We should declare at least .HomePage, "render"; in our policy or > we will never see the homepage. With just this the link will not be > rendered because it lacks .PageA, "render"; > So if we put that in the policy to we will see a disabled link. > (wicket turns it into a span by default) but because the component is > still available on the server side someone could spoof the url and > trigger wicket into thinking the link was clicked, fortunatly the > second check i mentioned earlier will detect this and send you to the > accessdenied page. > Only if we make sure our policy also contains .PageA, "enable"; > the link will be fully operational. > > I hope this answered your question. :) > > But if you want to get realy confused you should read on because there > is an alternative mode in which it is possible to show the link even > if we have not granted render to PageA. > I am actually working on some examples showing this alternate mode, > but they are not yet available. > To activate the alternate rendering mode you need to do this: > ((LinkSecurityCheck)link.getSecurityCheck()).setUseAlternativeRenderCheck(true); > Given the above example and a policy file only containing > HomePage, "inherit, render"; > the link will render as a disabled link. Note the inherit, this means > all child components on the homepage are allowed to render. Optionally > we could replace that one line with the following two lines > HomePage, "render"; and HomePage:link, "render"; Assuming the > wicket id of our link is link :) To enable the link we would still > require PageA, "enable"; in our policy. > > Thanks for checking out swarm and wasp, i hope i did not just confuse > the hell out you :) > > Maurice > > > > craigdd wrote: > > > > In look looking the getting started page for wicket security I came across > > the following block on text when describing the configuration of > > principals. > > > > What we just did is grant everyone the right to see (render) our HomePage, > > if there are secure components on the homepage we can see them too > > (inherit). In addition we granted links to our homepage the right to be > > clicked (enable). Because we do not want to give links on our homepage the > > right to be clicked we did not place the enable action on the previous > > line with the inherit. If we know for a fact that there are absolutely no > > links pointing to the homepage we could delete the second line, but > > generally you will want these two lines for any given secure page. If you > > think, what a long line isn't there a shorter way, then i have good news > > for you. Hive supports aliases. This means that besides the build in > > aliases for permissions you can add your own aliases for permissions, > > principals and names, just not for actions!. aliases can be concatenated > > but not nested. sow if we rewrite our policy to use aliases we get > > > > Just to clarify, when you say "In addition we granted links to our > > homepage the right to be clicked (enable)", does this mean that the link, > > which I assume you mean , is able to be physically clicked? And if it was > > the opposite, as is the next line of the configuration "HomePage", > > "enable"", does this mean that the link is disabled to the user, or that > > it is enabled but you will get an access error exception on the server > > side? > > > > Thanks > > Craig > > > > -- > View this message in context: > http://www.nabble.com/Wicket-Security-Configuration-Question-tf3884414.html#a11009846 > Sent from the Wicket - User mailing list archive at Nabble.com. > > > - > This SF.net email is sponsored by DB2 Express > Download DB2 Express C - the FREE version of DB2 express and take > control of your XML. No limits. Just data. Click to get it now. > http://sourceforge.net/powerbar/db2/ > ___ > Wi
Re: [Wicket-user] Wicket Security Configuration Question
This original post was under wicket stuff users list and I've reposted it hear for more visibility, as requested by Martijn. The following is the response that I got from Maurice. Hi, what i mean is this: By default SecurePageLink (and all other links with the same securitycheck) checks for an enable action on the page the link points to. This check occurs both in the render (where is decided if the link should be clickable) and in the onclick (just to check if nobody spoofed an url to trigger a link click where it is not allowed). Maybe an example will make things more clear (note to self to update the getting started) HomePage contains a SecurePageLink to PageA. We should declare at least .HomePage, "render"; in our policy or we will never see the homepage. With just this the link will not be rendered because it lacks .PageA, "render"; So if we put that in the policy to we will see a disabled link. (wicket turns it into a span by default) but because the component is still available on the server side someone could spoof the url and trigger wicket into thinking the link was clicked, fortunatly the second check i mentioned earlier will detect this and send you to the accessdenied page. Only if we make sure our policy also contains .PageA, "enable"; the link will be fully operational. I hope this answered your question. :) But if you want to get realy confused you should read on because there is an alternative mode in which it is possible to show the link even if we have not granted render to PageA. I am actually working on some examples showing this alternate mode, but they are not yet available. To activate the alternate rendering mode you need to do this: ((LinkSecurityCheck)link.getSecurityCheck()).setUseAlternativeRenderCheck(true); Given the above example and a policy file only containing HomePage, "inherit, render"; the link will render as a disabled link. Note the inherit, this means all child components on the homepage are allowed to render. Optionally we could replace that one line with the following two lines HomePage, "render"; and HomePage:link, "render"; Assuming the wicket id of our link is link :) To enable the link we would still require PageA, "enable"; in our policy. Thanks for checking out swarm and wasp, i hope i did not just confuse the hell out you :) Maurice craigdd wrote: > > In look looking the getting started page for wicket security I came across > the following block on text when describing the configuration of > principals. > > What we just did is grant everyone the right to see (render) our HomePage, > if there are secure components on the homepage we can see them too > (inherit). In addition we granted links to our homepage the right to be > clicked (enable). Because we do not want to give links on our homepage the > right to be clicked we did not place the enable action on the previous > line with the inherit. If we know for a fact that there are absolutely no > links pointing to the homepage we could delete the second line, but > generally you will want these two lines for any given secure page. If you > think, what a long line isn't there a shorter way, then i have good news > for you. Hive supports aliases. This means that besides the build in > aliases for permissions you can add your own aliases for permissions, > principals and names, just not for actions!. aliases can be concatenated > but not nested. sow if we rewrite our policy to use aliases we get > > Just to clarify, when you say "In addition we granted links to our > homepage the right to be clicked (enable)", does this mean that the link, > which I assume you mean , is able to be physically clicked? And if it was > the opposite, as is the next line of the configuration "HomePage", > "enable"", does this mean that the link is disabled to the user, or that > it is enabled but you will get an access error exception on the server > side? > > Thanks > Craig > -- View this message in context: http://www.nabble.com/Wicket-Security-Configuration-Question-tf3884414.html#a11009846 Sent from the Wicket - User mailing list archive at Nabble.com. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
[Wicket-user] Wicket Security Configuration Question
In look looking the getting started page for wicket security I came across the following block on text when describing the configuration of principals. What we just did is grant everyone the right to see (render) our HomePage, if there are secure components on the homepage we can see them too (inherit). In addition we granted links to our homepage the right to be clicked (enable). Because we do not want to give links on our homepage the right to be clicked we did not place the enable action on the previous line with the inherit. If we know for a fact that there are absolutely no links pointing to the homepage we could delete the second line, but generally you will want these two lines for any given secure page. If you think, what a long line isn't there a shorter way, then i have good news for you. Hive supports aliases. This means that besides the build in aliases for permissions you can add your own aliases for permissions, principals and names, just not for actions!. aliases can be concatenated but not nested. sow if we rewrite our policy to use aliases we get Just to clarify, when you say "In addition we granted links to our homepage the right to be clicked (enable)", does this mean that the link, which I assume you mean , is able to be physically clicked? And if it was the opposite, as is the next line of the configuration "HomePage", "enable"", does this mean that the link is disabled to the user, or that it is enabled but you will get an access error exception on the server side? Thanks Craig -- View this message in context: http://www.nabble.com/Wicket-Security-Configuration-Question-tf3884414.html#a11009812 Sent from the Wicket - User mailing list archive at Nabble.com. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Wicket-user mailing list Wicket-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wicket-user
