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
>
