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...
jonOn 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
johanOn 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
