You got it Rob. Thanks for your responses. I'll go the authenticate/authorize route.
Jeff On 9/16/07, Mitch Stewart <[EMAIL PROTECTED]> wrote: > > 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 > > > >
