You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@wicket.apache.org by Michael Sparer <mi...@gmx.at> on 2008/02/11 16:25:46 UTC
wicket-security, everybodyprincipal and only securepages
Hi,
I'm fiddling around with wasp and swarm. I was wondering if it is possible
to add an EverybodyPrincipal to the current session on session
instantiation.
The problem is the following: I'd like to let my BasePage (from which ALL
pages in my app inherit from) extend SecurePage to be able to control the
actions for all pages with the hive file. But as a SecurePage requires an
authenticated session, I can't let my basepage extend SecurePage.
So I thought, that I could just add a subject containing an
EverybodyPrincipal on session creation. I.e. in the session's constructor or
in the application's newSession method, sothat the session gets
authenticated behind the scenes and the page gets rendered fine.
Unfortunately this results in a Stackoverflow as the Session.get() method
calls the login method and vice-versa... so what's the best way to handle
that?
thanks in advance (to maurice i think ;-))
regards
Michael
-----
Michael Sparer
http://talk-on-tech.blogspot.com
--
View this message in context: http://www.nabble.com/wicket-security%2C-everybodyprincipal-and-only-securepages-tp15413102p15413102.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-security, everybodyprincipal and only securepages
Posted by Maurice Marrink <ma...@gmail.com>.
>I was wondering if it is possible
> to add an EverybodyPrincipal to the current session on session
> instantiation.
After reading your mail again, trying to recreate the stackoverflow, i
realize you said the EveryBodyPrincipal, the whole time i was reading
is as AllPermissions. :-s
The EveryBodyPrincipal is kind of strange in the sense that you do not
need to add it yourself to a user. It is automatically "assigned" to
every user if your policy contains one or more
grant
{
.....
};
blocks. Note the absence of the principal class and name.
So please don't use it yourself :)
Maurice
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: wicket-security, everybodyprincipal and only securepages
Posted by "Hoover, William " <wh...@nemours.org>.
ldap project has been put on hold for a more pressing project :(
I plan on getting something in place to address the ldap and mounting strategy as soon as I complete the current project I am working on :o)
You have done a great job with Wasp/Swarm and I think that it is worth me spending the extra time/effort to add these features!
-Will
-----Original Message-----
From: Maurice Marrink [mailto:marrink@gmail.com]
Sent: Tuesday, February 12, 2008 8:29 AM
To: users@wicket.apache.org
Subject: Re: wicket-security, everybodyprincipal and only securepages
Hey William,
How is the ldap integration comming along?
Like i said then, i don't have a solution ready for how you would do
such a thing, and frankly it doesn't bother me enough if sometimes i
have to implement ISecurePage myself.
But i welcome a contribution that could do it :)
Maurice
On Feb 12, 2008 1:29 PM, Hoover, William <wh...@nemours.org> wrote:
> I still think that a more elegant and non-obtrusive solution would be
>
> mountSecurePage(MySecureWebPage.class)
>
> discussed previously in: http://www.mail-archive.com/users@wicket.apache.org/msg09129.html
> That way you could have one basepage because they would not have to extend SecureWebPage
>
>
> -----Original Message-----
> From: Maurice Marrink [mailto:marrink@gmail.com]
> Sent: Tuesday, February 12, 2008 4:24 AM
> To: users@wicket.apache.org
> Subject: Re: wicket-security, everybodyprincipal and only securepages
>
>
> If i add an extra method isUserAuthenticated to my
> WaspAuthorizationStrategy, then yeah i probably could let wasp handle
> everything in the WaspSession class.
> I need to know if a user is logged in before i force the session to bind.
>
> Thnx Johan.
>
> Maurice
>
> On Feb 12, 2008 10:13 AM, Johan Compagner <jc...@gmail.com> wrote:
> > About stackoverflow, cant you do that code in attach() of the session?
> > (test ofcourse if you want to do it once)
> >
> >
> > On 2/12/08, Michael Sparer <mi...@gmx.at> wrote:
> > >
> > > hi maurice,
> > >
> > > thanks for your answers. The reason why I want to avoid to have two
> > > basepages (one implementing ISecurePage) is that if I wanted to change
> > > something, such as markup, in the basepage I'd have to change it at two
> > > places. Even worse if I extend my extended basepages further, there would
> > > always have to be one version that does implement ISecurePage and one that
> > > doesn't. So I'd end up adding two pages with the same markup everytime when
> > > I'd like to add a page.
> > >
> > > As you might have noticed my app can't be compared to an app such as an
> > > online-banking-app where you have one loginpage and the rest is behind the
> > > big door on secure pages. In my application there are some pages that are
> > > for registered members only but which do (or at least should) extend the
> > > same basepage as a regular page. So I thought I'll sign any visitor in by
> > > default, without any roles sothat they're able to access and render any
> > > component inside of
> > >
> > > grant { ... }
> > >
> > > and then if a user logs in with username and password, I'll give 'em a
> > > different role such as user and let them access and render anything inside
> > >
> > > grant user { ... }
> > >
> > > makes sense?
> > >
> > > ah yes, creating a stackoverflow: just call the session.login(LoginContext)
> > > method inside the session's constructor (or inside your application's
> > > newSession method) and let it return a subject, then line 84 of the
> > > logincontainer class calls Session.get() that in turn calls findAndCreate
> > > that in turn calls the session's constructor that in turn calls
> > > Session.get() ... and so on
> > >
> > > regards
> > > Michael
> > >
> > >
> > > Mr Mean wrote:
> > > >
> > > >>also the
> > > >> first page a user hits after logging in (usually the home page) is a
> > > >> candidate.
> > > > Sorry this is not correct, usually that page (the home page) is a
> > > > secure page to trigger the automatic login.
> > > > I was trying to find more examples of pages typically not secure but i
> > > > guess besides public pages on your app / site only the login page has
> > > > a valid reason to not be secure.
> > > >
> > > > Maurice
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > >
> > > >
> > > >
> > >
> > >
> > > -----
> > > Michael Sparer
> > > http://talk-on-tech.blogspot.com
> > > --
> > > View this message in context:
> > > http://www.nabble.com/wicket-security%2C-everybodyprincipal-and-only-securepages-tp15413102p15428636.html
> > > Sent from the Wicket - User mailing list archive at Nabble.com.
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-security, everybodyprincipal and only securepages
Posted by Maurice Marrink <ma...@gmail.com>.
Hey William,
How is the ldap integration comming along?
Like i said then, i don't have a solution ready for how you would do
such a thing, and frankly it doesn't bother me enough if sometimes i
have to implement ISecurePage myself.
But i welcome a contribution that could do it :)
Maurice
On Feb 12, 2008 1:29 PM, Hoover, William <wh...@nemours.org> wrote:
> I still think that a more elegant and non-obtrusive solution would be
>
> mountSecurePage(MySecureWebPage.class)
>
> discussed previously in: http://www.mail-archive.com/users@wicket.apache.org/msg09129.html
> That way you could have one basepage because they would not have to extend SecureWebPage
>
>
> -----Original Message-----
> From: Maurice Marrink [mailto:marrink@gmail.com]
> Sent: Tuesday, February 12, 2008 4:24 AM
> To: users@wicket.apache.org
> Subject: Re: wicket-security, everybodyprincipal and only securepages
>
>
> If i add an extra method isUserAuthenticated to my
> WaspAuthorizationStrategy, then yeah i probably could let wasp handle
> everything in the WaspSession class.
> I need to know if a user is logged in before i force the session to bind.
>
> Thnx Johan.
>
> Maurice
>
> On Feb 12, 2008 10:13 AM, Johan Compagner <jc...@gmail.com> wrote:
> > About stackoverflow, cant you do that code in attach() of the session?
> > (test ofcourse if you want to do it once)
> >
> >
> > On 2/12/08, Michael Sparer <mi...@gmx.at> wrote:
> > >
> > > hi maurice,
> > >
> > > thanks for your answers. The reason why I want to avoid to have two
> > > basepages (one implementing ISecurePage) is that if I wanted to change
> > > something, such as markup, in the basepage I'd have to change it at two
> > > places. Even worse if I extend my extended basepages further, there would
> > > always have to be one version that does implement ISecurePage and one that
> > > doesn't. So I'd end up adding two pages with the same markup everytime when
> > > I'd like to add a page.
> > >
> > > As you might have noticed my app can't be compared to an app such as an
> > > online-banking-app where you have one loginpage and the rest is behind the
> > > big door on secure pages. In my application there are some pages that are
> > > for registered members only but which do (or at least should) extend the
> > > same basepage as a regular page. So I thought I'll sign any visitor in by
> > > default, without any roles sothat they're able to access and render any
> > > component inside of
> > >
> > > grant { ... }
> > >
> > > and then if a user logs in with username and password, I'll give 'em a
> > > different role such as user and let them access and render anything inside
> > >
> > > grant user { ... }
> > >
> > > makes sense?
> > >
> > > ah yes, creating a stackoverflow: just call the session.login(LoginContext)
> > > method inside the session's constructor (or inside your application's
> > > newSession method) and let it return a subject, then line 84 of the
> > > logincontainer class calls Session.get() that in turn calls findAndCreate
> > > that in turn calls the session's constructor that in turn calls
> > > Session.get() ... and so on
> > >
> > > regards
> > > Michael
> > >
> > >
> > > Mr Mean wrote:
> > > >
> > > >>also the
> > > >> first page a user hits after logging in (usually the home page) is a
> > > >> candidate.
> > > > Sorry this is not correct, usually that page (the home page) is a
> > > > secure page to trigger the automatic login.
> > > > I was trying to find more examples of pages typically not secure but i
> > > > guess besides public pages on your app / site only the login page has
> > > > a valid reason to not be secure.
> > > >
> > > > Maurice
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > > For additional commands, e-mail: users-help@wicket.apache.org
> > > >
> > > >
> > > >
> > >
> > >
> > > -----
> > > Michael Sparer
> > > http://talk-on-tech.blogspot.com
> > > --
> > > View this message in context:
> > > http://www.nabble.com/wicket-security%2C-everybodyprincipal-and-only-securepages-tp15413102p15428636.html
> > > Sent from the Wicket - User mailing list archive at Nabble.com.
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
RE: wicket-security, everybodyprincipal and only securepages
Posted by "Hoover, William " <wh...@nemours.org>.
I still think that a more elegant and non-obtrusive solution would be
mountSecurePage(MySecureWebPage.class)
discussed previously in: http://www.mail-archive.com/users@wicket.apache.org/msg09129.html
That way you could have one basepage because they would not have to extend SecureWebPage
-----Original Message-----
From: Maurice Marrink [mailto:marrink@gmail.com]
Sent: Tuesday, February 12, 2008 4:24 AM
To: users@wicket.apache.org
Subject: Re: wicket-security, everybodyprincipal and only securepages
If i add an extra method isUserAuthenticated to my
WaspAuthorizationStrategy, then yeah i probably could let wasp handle
everything in the WaspSession class.
I need to know if a user is logged in before i force the session to bind.
Thnx Johan.
Maurice
On Feb 12, 2008 10:13 AM, Johan Compagner <jc...@gmail.com> wrote:
> About stackoverflow, cant you do that code in attach() of the session?
> (test ofcourse if you want to do it once)
>
>
> On 2/12/08, Michael Sparer <mi...@gmx.at> wrote:
> >
> > hi maurice,
> >
> > thanks for your answers. The reason why I want to avoid to have two
> > basepages (one implementing ISecurePage) is that if I wanted to change
> > something, such as markup, in the basepage I'd have to change it at two
> > places. Even worse if I extend my extended basepages further, there would
> > always have to be one version that does implement ISecurePage and one that
> > doesn't. So I'd end up adding two pages with the same markup everytime when
> > I'd like to add a page.
> >
> > As you might have noticed my app can't be compared to an app such as an
> > online-banking-app where you have one loginpage and the rest is behind the
> > big door on secure pages. In my application there are some pages that are
> > for registered members only but which do (or at least should) extend the
> > same basepage as a regular page. So I thought I'll sign any visitor in by
> > default, without any roles sothat they're able to access and render any
> > component inside of
> >
> > grant { ... }
> >
> > and then if a user logs in with username and password, I'll give 'em a
> > different role such as user and let them access and render anything inside
> >
> > grant user { ... }
> >
> > makes sense?
> >
> > ah yes, creating a stackoverflow: just call the session.login(LoginContext)
> > method inside the session's constructor (or inside your application's
> > newSession method) and let it return a subject, then line 84 of the
> > logincontainer class calls Session.get() that in turn calls findAndCreate
> > that in turn calls the session's constructor that in turn calls
> > Session.get() ... and so on
> >
> > regards
> > Michael
> >
> >
> > Mr Mean wrote:
> > >
> > >>also the
> > >> first page a user hits after logging in (usually the home page) is a
> > >> candidate.
> > > Sorry this is not correct, usually that page (the home page) is a
> > > secure page to trigger the automatic login.
> > > I was trying to find more examples of pages typically not secure but i
> > > guess besides public pages on your app / site only the login page has
> > > a valid reason to not be secure.
> > >
> > > Maurice
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> > >
> >
> >
> > -----
> > Michael Sparer
> > http://talk-on-tech.blogspot.com
> > --
> > View this message in context:
> > http://www.nabble.com/wicket-security%2C-everybodyprincipal-and-only-securepages-tp15413102p15428636.html
> > Sent from the Wicket - User mailing list archive at Nabble.com.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-security, everybodyprincipal and only securepages
Posted by Maurice Marrink <ma...@gmail.com>.
If i add an extra method isUserAuthenticated to my
WaspAuthorizationStrategy, then yeah i probably could let wasp handle
everything in the WaspSession class.
I need to know if a user is logged in before i force the session to bind.
Thnx Johan.
Maurice
On Feb 12, 2008 10:13 AM, Johan Compagner <jc...@gmail.com> wrote:
> About stackoverflow, cant you do that code in attach() of the session?
> (test ofcourse if you want to do it once)
>
>
> On 2/12/08, Michael Sparer <mi...@gmx.at> wrote:
> >
> > hi maurice,
> >
> > thanks for your answers. The reason why I want to avoid to have two
> > basepages (one implementing ISecurePage) is that if I wanted to change
> > something, such as markup, in the basepage I'd have to change it at two
> > places. Even worse if I extend my extended basepages further, there would
> > always have to be one version that does implement ISecurePage and one that
> > doesn't. So I'd end up adding two pages with the same markup everytime when
> > I'd like to add a page.
> >
> > As you might have noticed my app can't be compared to an app such as an
> > online-banking-app where you have one loginpage and the rest is behind the
> > big door on secure pages. In my application there are some pages that are
> > for registered members only but which do (or at least should) extend the
> > same basepage as a regular page. So I thought I'll sign any visitor in by
> > default, without any roles sothat they're able to access and render any
> > component inside of
> >
> > grant { ... }
> >
> > and then if a user logs in with username and password, I'll give 'em a
> > different role such as user and let them access and render anything inside
> >
> > grant user { ... }
> >
> > makes sense?
> >
> > ah yes, creating a stackoverflow: just call the session.login(LoginContext)
> > method inside the session's constructor (or inside your application's
> > newSession method) and let it return a subject, then line 84 of the
> > logincontainer class calls Session.get() that in turn calls findAndCreate
> > that in turn calls the session's constructor that in turn calls
> > Session.get() ... and so on
> >
> > regards
> > Michael
> >
> >
> > Mr Mean wrote:
> > >
> > >>also the
> > >> first page a user hits after logging in (usually the home page) is a
> > >> candidate.
> > > Sorry this is not correct, usually that page (the home page) is a
> > > secure page to trigger the automatic login.
> > > I was trying to find more examples of pages typically not secure but i
> > > guess besides public pages on your app / site only the login page has
> > > a valid reason to not be secure.
> > >
> > > Maurice
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > > For additional commands, e-mail: users-help@wicket.apache.org
> > >
> > >
> > >
> >
> >
> > -----
> > Michael Sparer
> > http://talk-on-tech.blogspot.com
> > --
> > View this message in context:
> > http://www.nabble.com/wicket-security%2C-everybodyprincipal-and-only-securepages-tp15413102p15428636.html
> > Sent from the Wicket - User mailing list archive at Nabble.com.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-security, everybodyprincipal and only securepages
Posted by Johan Compagner <jc...@gmail.com>.
About stackoverflow, cant you do that code in attach() of the session?
(test ofcourse if you want to do it once)
On 2/12/08, Michael Sparer <mi...@gmx.at> wrote:
>
> hi maurice,
>
> thanks for your answers. The reason why I want to avoid to have two
> basepages (one implementing ISecurePage) is that if I wanted to change
> something, such as markup, in the basepage I'd have to change it at two
> places. Even worse if I extend my extended basepages further, there would
> always have to be one version that does implement ISecurePage and one that
> doesn't. So I'd end up adding two pages with the same markup everytime when
> I'd like to add a page.
>
> As you might have noticed my app can't be compared to an app such as an
> online-banking-app where you have one loginpage and the rest is behind the
> big door on secure pages. In my application there are some pages that are
> for registered members only but which do (or at least should) extend the
> same basepage as a regular page. So I thought I'll sign any visitor in by
> default, without any roles sothat they're able to access and render any
> component inside of
>
> grant { ... }
>
> and then if a user logs in with username and password, I'll give 'em a
> different role such as user and let them access and render anything inside
>
> grant user { ... }
>
> makes sense?
>
> ah yes, creating a stackoverflow: just call the session.login(LoginContext)
> method inside the session's constructor (or inside your application's
> newSession method) and let it return a subject, then line 84 of the
> logincontainer class calls Session.get() that in turn calls findAndCreate
> that in turn calls the session's constructor that in turn calls
> Session.get() ... and so on
>
> regards
> Michael
>
>
> Mr Mean wrote:
> >
> >>also the
> >> first page a user hits after logging in (usually the home page) is a
> >> candidate.
> > Sorry this is not correct, usually that page (the home page) is a
> > secure page to trigger the automatic login.
> > I was trying to find more examples of pages typically not secure but i
> > guess besides public pages on your app / site only the login page has
> > a valid reason to not be secure.
> >
> > Maurice
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> > For additional commands, e-mail: users-help@wicket.apache.org
> >
> >
> >
>
>
> -----
> Michael Sparer
> http://talk-on-tech.blogspot.com
> --
> View this message in context:
> http://www.nabble.com/wicket-security%2C-everybodyprincipal-and-only-securepages-tp15413102p15428636.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-security, everybodyprincipal and only securepages
Posted by Maurice Marrink <ma...@gmail.com>.
On Feb 12, 2008 9:24 AM, Michael Sparer <mi...@gmx.at> wrote:
>
> hi maurice,
>
> thanks for your answers. The reason why I want to avoid to have two
> basepages (one implementing ISecurePage) is that if I wanted to change
> something, such as markup, in the basepage I'd have to change it at two
> places.
I don't think this is true, consider the following class hierarchy
BasePage extends WebPage (has own markup file, probably containing
wicket:child tag)
MySecurePage extends BasePage implements ISecurePage (has no markup file)
Every other page either extends BasePage or MySecurePage
This way you only need to modify BasePage if you want to make some
layout changes to all your pages
>Even worse if I extend my extended basepages further, there would
> always have to be one version that does implement ISecurePage and one that
> doesn't. So I'd end up adding two pages with the same markup everytime when
> I'd like to add a page.
Maybe i am missing the point but why would you have 2 versions of a
page one secure and the other not.
If you are trying to build a page that contains both secure an
insecure content, you have 2 options
-let your page extend BasePage (as designed above) and place all
content on it (both secure and insecure)
If you have a lot of content that needs to be secure (in effect
wicket components) you might want to consider grouping it together in
a Panel.
I'll asume you have a Panel with all you secure content but the same
goes for any type or number of components
Add a ComponentSecurityCheck (or any check you like) to the component
(using SecureComponentHelper)
Then add permissions for the secure part to your policy file
grant org.MyPrincipal "regular user"
{
permission ${ComponentPermission} "org.MyPage:mySecureContent",
"inherit, render";
//the part after the : represents the wicket path to the component
as seen from the page, all components are separated by : so you might
get something like org.MyPage:mypanel:mytextfield
}
Because the page itself is not secure it is always rendered, and
because a ComponentSecurityCheck typically does not check for
authentication a guest will always see the page without the secure
content, a logged in user however (with the correct principals) always
sees all content.
-let your page extend MySecurePage (as designed above), like the
previous option you add a check to content you want to secure.
you add the same permission to your policy file and in addition you
add the page to the general grant block
grant
{
permission ${ComponentPermission} "org.MyPage", "render"; //do not
use inherit here
}
This way the user is required to log in but all user will be able to
see the nonsecure content of the page, only users with sufficient
permissions will see the secure content
>
> As you might have noticed my app can't be compared to an app such as an
> online-banking-app where you have one loginpage and the rest is behind the
> big door on secure pages. In my application there are some pages that are
> for registered members only but which do (or at least should) extend the
> same basepage as a regular page.
If you want a site with a public and restricted area, all you have to
do is let the public pages extend BasePage and the restricted pages
MySecurePage as shown above. All you pages will share the same
(single) markup.
> So I thought I'll sign any visitor in by
> default, without any roles sothat they're able to access and render any
> component inside of
>
> grant { ... }
>
> and then if a user logs in with username and password, I'll give 'em a
> different role such as user and let them access and render anything inside
>
> grant user { ... }
>
> makes sense?
Yep i get where you are going but i would not do it by automatically
signing in people as guests.
>
> ah yes, creating a stackoverflow: just call the session.login(LoginContext)
> method inside the session's constructor (or inside your application's
> newSession method) and let it return a subject, then line 84 of the
> logincontainer class calls Session.get() that in turn calls findAndCreate
> that in turn calls the session's constructor that in turn calls
> Session.get() ... and so on
Yeah i found those lines. The thing is i added those lines to support
clustering. And the only way you are going to get there is if your
LoginContext specifies multiple logins are allowed, which is probably
what you are doing after reading your story :)
I'll see if i can come up with an elegant solution for this.
In the mean time, i think i have given you a couple of ideas on how to
proceed without automatically logging someone in.
Let me know if you have any more questions.
Maurice
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-security, everybodyprincipal and only securepages
Posted by Michael Sparer <mi...@gmx.at>.
hi maurice,
thanks for your answers. The reason why I want to avoid to have two
basepages (one implementing ISecurePage) is that if I wanted to change
something, such as markup, in the basepage I'd have to change it at two
places. Even worse if I extend my extended basepages further, there would
always have to be one version that does implement ISecurePage and one that
doesn't. So I'd end up adding two pages with the same markup everytime when
I'd like to add a page.
As you might have noticed my app can't be compared to an app such as an
online-banking-app where you have one loginpage and the rest is behind the
big door on secure pages. In my application there are some pages that are
for registered members only but which do (or at least should) extend the
same basepage as a regular page. So I thought I'll sign any visitor in by
default, without any roles sothat they're able to access and render any
component inside of
grant { ... }
and then if a user logs in with username and password, I'll give 'em a
different role such as user and let them access and render anything inside
grant user { ... }
makes sense?
ah yes, creating a stackoverflow: just call the session.login(LoginContext)
method inside the session's constructor (or inside your application's
newSession method) and let it return a subject, then line 84 of the
logincontainer class calls Session.get() that in turn calls findAndCreate
that in turn calls the session's constructor that in turn calls
Session.get() ... and so on
regards
Michael
Mr Mean wrote:
>
>>also the
>> first page a user hits after logging in (usually the home page) is a
>> candidate.
> Sorry this is not correct, usually that page (the home page) is a
> secure page to trigger the automatic login.
> I was trying to find more examples of pages typically not secure but i
> guess besides public pages on your app / site only the login page has
> a valid reason to not be secure.
>
> Maurice
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
>
-----
Michael Sparer
http://talk-on-tech.blogspot.com
--
View this message in context: http://www.nabble.com/wicket-security%2C-everybodyprincipal-and-only-securepages-tp15413102p15428636.html
Sent from the Wicket - User mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-security, everybodyprincipal and only securepages
Posted by Maurice Marrink <ma...@gmail.com>.
>also the
> first page a user hits after logging in (usually the home page) is a
> candidate.
Sorry this is not correct, usually that page (the home page) is a
secure page to trigger the automatic login.
I was trying to find more examples of pages typically not secure but i
guess besides public pages on your app / site only the login page has
a valid reason to not be secure.
Maurice
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org
Re: wicket-security, everybodyprincipal and only securepages
Posted by Maurice Marrink <ma...@gmail.com>.
First off i would like to see your code as it should not be possible
to create a StackOverFlow.
Second i am not entirely sure why you would want EVERY page to be a secure page.
For instance the login page should not be a secure page, also the
first page a user hits after logging in (usually the home page) is a
candidate.
Anyway since you probably want every page to extend BasePage why not
have a subclass that implements ISecurePage and have all your pages
that should be secure extend that page.
For the implementation of ISecurePage you can simply redirect all
calls to the SecureComponentHelper.
Another option to grant permissions to every user is to put them in a
grant block without a principal like this:
grant
{
//permissions here
};
Note that you do need a logged in user for this to work.
If this is not what you are looking for then how about a little example.
Maurice
On Feb 11, 2008 4:25 PM, Michael Sparer <mi...@gmx.at> wrote:
>
> Hi,
>
> I'm fiddling around with wasp and swarm. I was wondering if it is possible
> to add an EverybodyPrincipal to the current session on session
> instantiation.
> The problem is the following: I'd like to let my BasePage (from which ALL
> pages in my app inherit from) extend SecurePage to be able to control the
> actions for all pages with the hive file. But as a SecurePage requires an
> authenticated session, I can't let my basepage extend SecurePage.
> So I thought, that I could just add a subject containing an
> EverybodyPrincipal on session creation. I.e. in the session's constructor or
> in the application's newSession method, sothat the session gets
> authenticated behind the scenes and the page gets rendered fine.
> Unfortunately this results in a Stackoverflow as the Session.get() method
> calls the login method and vice-versa... so what's the best way to handle
> that?
>
> thanks in advance (to maurice i think ;-))
>
> regards
>
> Michael
>
> -----
> Michael Sparer
> http://talk-on-tech.blogspot.com
> --
> View this message in context: http://www.nabble.com/wicket-security%2C-everybodyprincipal-and-only-securepages-tp15413102p15413102.html
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
> For additional commands, e-mail: users-help@wicket.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@wicket.apache.org
For additional commands, e-mail: users-help@wicket.apache.org