Your URL looks similar to some work that I have done, and I've gone down
the path that Rob has mentioned. I have an extended Guard which
overrides both the authenticate(...) method and the authorize(...)
method.
In the authenticate, we validate the username/password against a single
user database regardless of account, then within the authorize(...)
method we validate that the user has the appropriate permissions to
access the account and/or the protected resource. Both methods give you
the Request object so you can pretty much do what you want from that
point.
Mitch
________________________________
From: Rob Heittman [mailto:[EMAIL PROTECTED]
Sent: Sunday, September 16, 2007 2:44 PM
To: [email protected]
Subject: Re: Guard question
So each account has its own user community, in effect:
account1
alice/secreta
bob/secretb
account2
alice/secretx
eve/secrety
account1/alice (identified by secreta) is not the same as
account2/alice (identified by secretb)?
I guess my personal thought on this is that the ability to just
populate the getSecrets() map and/or override findSecrets() is meant to
be *very* simple, single-community, String lookup behavior for folks
with a fairly minimal authentication case. With a situation like yours
-- multiple communities you need to select between based on context --
you probably should be overriding at a little higher level, as you are
at authenticate(...).
If I misunderstood, and you do have a single community of
principals (alice always is the same alice, with the same password) but
you need to validate that alice is allowed to get into account2, then
I'd say the right place to do this is by overriding authorize(...),
which does get the Request passed.
----- Original Message -----
From: "Jeff Walter" <[EMAIL PROTECTED]>
To: [email protected]
Sent: Sunday, September 16, 2007 12:16:24 PM (GMT-0500)
America/New_York
Subject: Re: Guard question
I have a situation like this:
/accounts/{accountID}/protectedResource
I have a router which routes /accounts/{accountID}, next in line
is my Guard (using basic HTTP auth), then the protectedResource.
Each account in my system has its own set of logins. To get to
the protectedResource, you must provide login credentials which are
valid for your account, hence my findSecret method needing the
{accountID} from the Request to do the lookup. I don't think chained
Guards would help in my situation.
I'm okay with the overrides I'm doing now, but I thought my
situation might be general enough to foster a discussion/potential
change. Any other thoughts?
-Jeff
On 9/15/07, Rob Heittman <[EMAIL PROTECTED]> wrote:
Hi Jeff,
I'd say it makes sense the way it is; most two-factor
systems can look up the second factor given only the username,
certificate-hash, or some other Stringified representation of the first
factor. For a multi-factor system, chained Guards sometimes work well
to do multiple checks with less overrides, e.g. username vs. IP in one
Guard, username vs. password in the next Guard. Where the factors are
interrelated in someway so a chain of Guards wouldn't work, IMO, that
would be fairly fringey.
Can you provide any details on why the Request is needed
for the lookup in your case? There might be a different way to do it,
or the details might shed light on potential API improvements.
- Rob
----- Original Message -----
From: "Jeff Walter" <[EMAIL PROTECTED]>
To: [email protected]
Sent: Saturday, September 15, 2007 12:20:58 PM
(GMT-0500) America/New_York
Subject: Guard question
I have a Guard whose findSecret(String) method needs the
Request from the authenticate(Request) method. Right now I am overriding
authenticate to call my own checkSecret method (which calls my own
findSecret method, passing down the Request from authenticate). Does it
make sense for the framework pass down the Request, or is my case so
much on the fringe that I should just stick to what I'm doing?
Best,
Jeff
