Currently we don't protect internal pages like the inspector bug page. We should of course, but the question is what would be the best way to do this. I think we have two opions:
1) Do it with the normal IAuthorizationStrategy. In this case, instead of the current installation of IAuthorizationStrategy.ALLOW_ALL, we would have a default strategy that would either allow all when in development mode, or deny all internal pages in production mode. * pro: consistent approach to all authorization * con: if you install a custom authorization strategy you have to know about this/ custom strategies have to consider these internal pages as special cases. 2) Do it with a seperate IAuthorizationStrategy. For instance, besides the current ISecuritySettings.get/setAuthorizationStrategy there would be something like ISecuritySettings.get/setInternalAuthorizationStrategy. Again, in dev mode, this would default to an allow all strategy, and in production mode a deny all. * the pros/cons are the oposite of the ones of 1) Any thoughts on this? Eelco ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642 _______________________________________________ Wicket-develop mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-develop
