Authentication - more oop

Not for 'how-to' coding questions but PHP theory instead, this forum is here for those of us who wish to learn about design aspects of programming with PHP.

Moderator: General Moderators

User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Ambush Commander wrote:The first trouble is establishing the session, since as it stands right now, there's no facility for making sure that the user doesn't have to log in every page request. I would say that the return value isAuthorized(), but we'll also need a user id. There's two ways to go about doing this:
I'm not sure what need the user id, but I would hope it would it would be contained in the Credential and accessed only by the Authenticator (I think I misnamed in Authorizor which is incorrect) If the system needs to save information in the session, and I don't think this code would, then probably you would pass the Credential to the Access Control system which is a whole separate thing from this Authentication stuff.
Ambush Commander wrote:1. Simple (and hacky): Have isAuthorized() return the user ID: it still works as a boolean but also tells us who the user is.
2. Complicated (but extensible): Create an AuthorizationStatus object that holds the user ID, as well as anything else that could possibly be useful for authorization (like whether or not the user logged in via a real login or remember me).

Let's add a Captcha now. Say instead of a regular User Password login, now we need a Captcha to be verified too (we'll assume that some other part of the application automatically changes the authorizer). While we could extend the Authorizor_UsernamePassword class, I think creating an Authorizor_Composite and Authorizor_Captcha would be far more reusable. The composite authorizor would require that all the authorizors it consists of pass for it to say "authorized!" while the Captcha authorizor would solely check whether or not the Captcha works. We'd also need a CompositeCredential class.
I think Captcha would just add another Term to the Credential/Authenticator. An alternative would be to have a chain of Authenticators, so you could add a username/password Authenticator and a Capcha Authenticator to the chain. Again, the Authenticate class would just me a generic manager.

But perhaps I am not understanding you.
(#10850)
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

I'm not sure what need the user id,
A few off the top of my head:
- You are currently logged in as USERNAME (okay, so maybe not a user id, but it's close)
- Logging user actions
- Identifying a user as that user
but I would hope it would it would be contained in the Credential and accessed only by the Authenticator (I think I misnamed in Authorizor which is incorrect) If the system needs to save information in the session, and I don't think this code would, then probably you would pass the Credential to the Access Control system which is a whole separate thing from this Authentication stuff.
Ehhh... why would the access control system have anything to do with persisting authentication state? I assume that you're not recommending we put the credential itself in the session.
I think Captcha would just add another Term to the Credential/Authenticator.
Well, we obviously won't want to duplicate functionality, so this implies an extends of some sorts. What happens, then, if multiple authenticators want to use the captcha?
An alternative would be to have a chain of Authenticators, so you could add a username/password Authenticator and a Capcha Authenticator to the chain. Again, the Authenticate class would just me a generic manager.
That would, essentially, be the same as the composite, with an extra optimization: if one of the checks fails, abort the rest of the checks. It's not a chain in the sense that username/password looks at the credentials, does no work, and then passes it to the captcha. If the chain ends with success, all the authenticators have to finish.

Ninja Space Goat - Isn't that the check you would do when logging a user in? I think it's overkill: if $_SESSION says that ['user_id'] is authenticated, you ought to trust it. I think it's overkill. The processing you should be doing each request is making sure a session hasn't expired/idled out.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Ambush Commander wrote:Ehhh... why would the access control system have anything to do with persisting authentication state? I assume that you're not recommending we put the credential itself in the session.
No, my point was that once authenticated then whatever desired information would be given to the rest of the Access Control system to save in the session -- credentials would no longer be needed, but as you mention the username or name might be.
Ambush Commander wrote:Well, we obviously won't want to duplicate functionality, so this implies an extends of some sorts. What happens, then, if multiple authenticators want to use the captcha?
First I see not reason not to duplicate some functionality as many of these schemes are trivial variations of each other. And I'm not sure what you mean by "want to use the captcha"? Capthca is just another term in authentication, no different that username or password -- it has a source and it gets checked.
Ambush Commander wrote:That would, essentially, be the same as the composite, with an extra optimization: if one of the checks fails, abort the rest of the checks. It's not a chain in the sense that username/password looks at the credentials, does no work, and then passes it to the captcha. If the chain ends with success, all the authenticators have to finish.
It could be Chain of Resposiblity, although I would probably prefer a straight Chain because then I could gather all error messages and report back fully.
(#10850)
Post Reply