sorry. you're correct. the enabled action is actually preferred in general for this because the framework does a variety of other checks beyond just rendering. for example, you cannot submit a form that has been found to be disabled by security.
igor.vaynberg wrote: > > but there is also an enabled action that can work very well for this. if > the > page is not enabled it wont be rendered > > -igor > > > On 2/27/07, Jonathan Locke <[EMAIL PROTECTED]> wrote: >> >> >> >> you are correct that there is an underlying assumption that a user's >> roles >> cannot change within a session. to solve that problem right now, you >> would >> have to manually call Session.clear(), clearing all pagemaps in the >> user's >> session. why do you think that would not work? (aside from whatever's >> broken in head right now) >> >> also, i'm not sure if your solution to check on retrieving from the page >> map >> works if we want to prevent access to as well as instantiation of >> components. >> remember, there can be references to protected components stored in >> fields >> of components or the session. it's very uncontrolled this way. if you >> really >> want to be sure about checking access to a component, the best way is to >> check on rendering. you can already do that now. just don't let your >> component >> perform the RENDER action unless the users is authorized to do it. >> >> >> Martin Benda wrote: >> > >> > Hi, >> > >> > isn't IAuthorizationStrategy#isInstantiationAuthorized() quite prone to >> > security related bugs? Authorization is checked only when a page (or >> any >> > other component) is instantiated - the page instance is then stored in >> a >> > page >> > map. After a user logs out he can still access these secured pages >> stored >> > in >> > the page map. This IMHO opens dangerous security holes in secured >> wicket >> > applications... >> > >> > One possible solution is to call Session.get().clear() when a user logs >> > out - >> > but it won't work when user's authorization can dynamically change >> during >> > his >> > session (e.g. roles are added or removed). >> > >> > Moreover, Session.get().clear() does not work in current wicket-2.0 >> > snapshot >> > (I just created WICKET-331 issue). >> > >> > I think that there should be a mechanism that checks authorization >> > everytime a >> > page instance is created or retrieved from a page map. Something like >> > isAccessAuthorized(Class<? extends Page> pageClass). Another question: >> do >> > we >> > need this fine-grained isInstantisationAuthorized(componentClass) at >> all? >> > >> > WDYT? >> > >> > Regards, >> > Bendis >> > >> > >> >> -- >> View this message in context: >> http://www.nabble.com/Is-IAuthorizationStrategy-isInstantiationAuthorized-prone-to-security-bugs--tf3299965.html#a9186998 >> Sent from the Wicket - Dev mailing list archive at Nabble.com. >> >> > > -- View this message in context: http://www.nabble.com/Is-IAuthorizationStrategy-isInstantiationAuthorized-prone-to-security-bugs--tf3299965.html#a9188261 Sent from the Wicket - Dev mailing list archive at Nabble.com.
