i can't believe this problem. i've spent so many hours thinking
about wicket security. patching every little mouse hole i could
think of... and here it was my inspector feature that left the
front door wide open! what a forehead slapper! man i am an idiot
sometimes!! DOH!!
to solve, i think 2 is better than 1 because 1 is error prone
and could expose sites to attack without the developer being
aware of it.
but a third possibility i like better is:
3. don't create an auth strategy at all but instead abstract
each internal feature by putting a flag in the settings object
exposed through appropriate interfaces. for now, i'd have the
implementation of this dump out a very visible security warning
when the server starts up and any unsafe feature is on (just like
the warning for developer mode). to implement, just manually check
for the corresponding debug mode in the constructor of each internal
page of this nature (just the inspector and ajax debugger so far)
and throw an exception if it's disallowed. it would be nice to
also auto-hide the corresponding buttons (filed an RFE to make these
look similar today) that bring the features up so devs don't have to.
in the future if we have enough internal features of this nature
we can consider a more general strategy and the change won't be
visible to users. for now, i think this is quite small, special
and internal and abstracting it through settings is probably the
best way.
jon
---
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
