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#a9201709 Sent from the Wicket - Dev mailing list archive at Nabble.com.
