Absolutely. Provides the best guarantee since it clears anything in the Session object of the user too.
Johan Compagner wrote: > > but still: > > session.invalidate() instead of clear() is a much better solution anyway. > > johan > > > On 2/28/07, Martin Benda <[EMAIL PROTECTED]> wrote: >> >> Well, you are right. Now I see that there should be no problems with >> isInstantiationAuthorized when Session.clear() is used consistently... >> Sorry >> for my confused arguments :-) >> >> Thanks, >> Bendis >> >> On Wednesday 28 of February 2007 11:52:01 Jonathan Locke wrote: >> > you're quoting me a bit out of context here because i was talking about >> > why your solution to check things on removal from pagemap wouldn't >> > work completely. but that argument was a sidetrack because i never >> > agreed such a check was either necessary or desirable for full >> security. >> > >> > it's logically sufficient to just check component instantiation if your >> > user is in a constant role because they can't even create a component >> to >> > misuse in the first place. and in the case where the user is not in a >> > constant role >> > (admin change), you ought to be dumping their session with >> Session.clear >> () >> > after the role change as we discussed. and, of course, from that point >> > on they will be constant in the new role, making instantiation checks >> once >> > again sufficient. >> > >> > so the only sound reason to do the ENABLE check at all is if you're >> doing >> > fine-grained security (which is the intent of that check), meaning >> you're >> > putting a panel or other component on a page with a different >> > authorization. >> > >> > i can see where you got started thinking there might be a problem, but >> > aside from the need to call Session.clear() when role switching, i >> don't >> > see one. and the two mechanisms provide important and independent >> > functionality, not redundancy. >> > >> > Martin Benda wrote: >> > >> 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. >> > > >> > > When it comes to security, you should by always *really* sure :-) And >> if >> > > that >> > > means that every component secured by isInstantiationAuthorized >> should >> be >> > > also secured by isActionAuthorized (ENABLE or RENDER) just to be >> sure, >> > > isn't >> > > isInstantiationAuthorized redundant? This was the original idea that >> led >> > > me >> > > to start this thread... >> >> >> > > -- View this message in context: http://www.nabble.com/Is-IAuthorizationStrategy-isInstantiationAuthorized-prone-to-security-bugs--tf3299965.html#a9206790 Sent from the Wicket - Dev mailing list archive at Nabble.com.
