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
