On 2/6/06, Johan Compagner <[EMAIL PROTECTED]> wrote: > Hi, > > Now we have a new Security build in in wicket (IAuthorizationStrategy) we > don't really need Page.checkAccess() anymore > At least we think we don't need it anymore, we still need to check usecases.
I'm positive we don't need it anymore. We night need another pattern as the current one isn't as easy to use as checkAccess, though at least now the contract is pretty tight instead of fuzzy like it has always been. Usually, just implementing wicket.authorization.IAuthorizationStrategy#authorizeInstantiation(java.lang.Class) should be enough for your needs. If you check on that level, page/ component instances will never be created at all if you deny them. > For example i have access to the page at first, but i keep a reference to > it. And i set it again as a response page some later time > then we still must go to the same easy check if i still have the rights to > see that page or not. > (don't know currently how easy that is, maybe eelco can explain this) Yeah that case, and the case where you allow access now, the user logs off, and pushes the back button a couple of times thus not forcing construction but instead 'reconstruction' from the session again. Cases like that can be handled through method wicket.authorization.IAuthorizationStrategy#authorizeAction(wicket.Component, wicket.authorization.Action) So if you really want to have your security tight, you probably use both IAuthorizationStrategy's methods. We might consider calling authorizeInstantiation on page reconstruction too. That would at least fix that one transparenty. Or maybe we're just making it too difficult then. > > But currently there is a problem how we handle checkAccess first it is not > in the sync block as it should be. > Second it doesn't work quite right currently if the RequestTarget is and > ListenerInterfaceRequestTarget because > that target gets a checkaccess but it does the checkAccess on the page where > the event is being called on (in one step later) > (this was not the case in 1.1 the page was not checked again when a > interface was called, this is a nice addition in 1.2 if you ask me) > > But if that checks goes fine then we come in the process event and response > phase. That process event is setting another page as the > response phase. And that page will be rendered now without any check. > > So if we keep page.checkAccess() in 1.2 we need to rewrite that checkaccess > step and fold it into the processEventsAndResponse step. > So that it is synced and check access is called on the right response page. > > So what do we want? And is the new thing as easy to implement for the most > things people are using it for (check for the user and redirect to a login > page) The new way of doing things isn't as straigforward as the old way, though the old way was a good example of over-simplification. I'm all for getting rid of checkAccess sooner than later if it is in our way of making the request processing solid. If I can get to it, I'll convert the checkAccess calls in wicket-examples this week to show how it can work. Eelco ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnk&kid3432&bid#0486&dat1642 _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
