I don't like any authentication. There are many posibilities to implement authentication, and just picking one totally doesn't make sense to me. Any solution should be authorization based, nothing more than that. *On top of that* we might provide a login form or whatever to implement what you want Johan.
Eelco On 4/21/06, Jonathan Locke <[EMAIL PROTECTED]> wrote: > also, when you're running in development mode, nobody wants to type > a password all the time. maybe it should only be required in deployment > mode? > > > On 4/21/06, Jonathan Locke <[EMAIL PROTECTED]> wrote: > > > > well, that sounds better. but it seems like it's separate from what > features > > are actually enabled. i still might want to turn off session viewing even > if > > you can access ajax debugging with the right password. so maybe both? > > > > > > > > On 4/21/06, Johan Compagner < [EMAIL PROTECTED]> wrote: > > > > > > you do have an OFF switch!! (and it is in the OFF switch by default) > > > Don't specify the user/password that can access the internal pages. > > > Because that is what must be configured by the developer. Default it is > null/null so you can't go into it at all. we immediantly throw an access > denied page > > > (not even asking for the login codes because we already see that we > can't check it because the user/password combo is not specified) > > > > > > When a developer does specify it in the ISecuritySettings so it does say > "admin", "password" > > > Then we see that and ask the user to authenticate itself. > > > > > > > > > johan > > > > > > > > > > > > > > > On 4/21/06, Jonathan Locke < [EMAIL PROTECTED]> wrote: > > > > > > > > > > > > i really don't like the idea of relying on a mechanism like BASIC auth > for something as dangerous as being able to view all session data. really > secure sites might be very very upset if they found out this was going on > and they didn't know about it. i prefer to have an on/off switch for this > globally... have it off by default in deployment mode and on in development > mode and of course print a very visible warning whenever it's on. i > forwarded my third option to you and the admin list... i don't know if it > was ever posted to wicket-develop... it didn't seem to show up in the > archive... > > > > > > > > jon > > > > > > > > > > > > > > > > On 4/21/06, Johan Compagner < [EMAIL PROTECTED]> wrote: > > > > > > > > > > i think i want a third option. > > > > > Because in production the LiveSessionPage is interessting (it needs > some more work but it is very good at showing what really happens) > > > > > that page is in development mode even not that interessting at all. > > > > > > > > > > I still think something like basic authentication for those pages. > So all internal pages are subclasses from a basic 'security' page > > > > > and that page can only be accessed when the user is logged in by > basic http authentication. Just like tomcat and i guess more app servers > > > > > also use for the basic security (like the default management apps > they ship) > > > > > > > > > > also: > > > > > with 1 people are going to forget this to check on there own. > > > > > with 2 you have just as with 1? so development mode can do > everything and deployment nothing? What happens if people just run in > development mode for a while? > > > > > > > > > > I just think we shouldn't use development/deployment mode for this. > but just an internal thing using basic authentication > > > > > > > > > > johan > > > > > > > > > > > > > > > > > > > > On 4/21/06, Maurice Marrink <[EMAIL PROTECTED]> wrote: > > > > > > I would vote for option 1. > > > > > > The con could be largely negated if we have some sort of tagging > > > > > > ISecurePage interface. > > > > > > these internal pages would then implement this interface, custom > > > > > > strategys could then easily check for these type of pages. If i am > not > > > > > > mistaken this is already the way the strategys are supposed to > work. > > > > > > > > > > > > Maurice > > > > > > > > > > > > On 4/21/06, Eelco Hillenius < [EMAIL PROTECTED]> wrote: > > > > > > > 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?cmdlnk&kid0709&bid&3057&dat1642 > > > > > > > _______________________________________________ > > > > > > > Wicket-develop mailing list > > > > > > > [email protected] > > > > > > > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- > > > > > > 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?cmdlnk&kid0709&bid&3057&dat1642 > > > > > > _______________________________________________ > > > > > > Wicket-develop mailing list > > > > > > [email protected] > > > > > > > https://lists.sourceforge.net/lists/listinfo/wicket-develop > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------------------------------- 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
