Hmm, usually there is no need to change the guest permissions on the fly.
In that case you can just implement ISecurePage on every page that
needs to be secure and not on the "guest" pages.
On Fri, Jul 18, 2008 at 10:14 AM, Gabriel Bucher
<[EMAIL PROTECTED]> wrote:
> hi all,
>
> I did some test to implement a guest auto login with swarm/wasp. I'm just
> not sure if I'm digging in the right direction.
>
> my scenario is the following:
> - all pages are implementing the interface ISecurePage
> - all pages are grouped in different principals (hive)
> - i have an admin gui for setting principals for an individual user
>
> main goal is, that we can set for each page if you need to be logged in or
> not, depend on the user self, means we can have certain pages public depend
> on the scenario.
Implementing ISecurePage means that a subject needs to be present for this page.
This is enforced by a ClassSecurityCheck which is automatically used
when checking for access permissions.
This call ultimately ends in asking the subject if the class is
authenticated. (It first passes through the LoginContainer but that is
not easily customizable (yet))
It is also possible to only do the access check for pages implementing
a custom interface, but i don't think that will help in your case
because, as i understand it, you want to change which pages are
accessible by guests on the fly.
>
> what i did so fare:
> - implemented 2 LoginContext, one for the guest and one for the acutal login
> if a user needs to be logged in!
Yes, this is required because of the above mentioned restriction.
> - to do the auto login, i did a login( new GuestLoginContext()) when the
> session is created, on that way, the webuser can access all principals which
> are assigned to this special user 'guest'.
Yes also because of the above mentioned restriction you need a
subject. on session creation is the most logical place to do that.
You might be able to put a few pages which are sure not to be changed
on the fly in an anonymous grant block.
grant
{
....
};
that way every user, guest or otherwise will have those permissions.
but judging from your story i doubt there will be many pages this
applies to.
> - additionally the GuestLoginContext has his own Subject implementation
> which i override isClassAuthenticated(Class class1) to check if the guest
> user is allowed to access the class, currently i use the following
> getStrategy().isClassAuthorized(class1,
> getActionFactory().getAction(Access.class));
By default a subject returns true for isClassAuthenticated, so yes if
you want to customize this, then this is the place.
I am not sure i agree with you using the authorized calls to check for
authentication but that is probably nitpicking :) It certainly gets
the job done.
>
> I'm not sure if this is a way to go to implement such a scenario. If someone
> else implemented a similar scenario, I'm happy to get some more advice.
That was a lot of writing just to say, i think you are on the right track :)
Mind you that i never tried any of this myself.
Maurice
>
> thanks gab
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
