Page 1 of 1

Do you use a localized singleton authentication class?

Posted: Mon Aug 20, 2007 3:37 pm
by joncampbell
Do you use a localized singleton authentication class in your frameworks? I am creating my first framework and was thinking about creating it using a singleton pattern for my authentication class, I was hoping that someone here could tell me what they have done in the past, and maybe the pros and cons of using this logic.

Thank you in advance :P

Posted: Mon Aug 20, 2007 4:00 pm
by feyd
I don't use Singletons in PHP, nor would I recommend using them. A Registry is better suited for the task of serving the instance. We've had discussions on Singletons and Registries, please seek them out.

Posted: Mon Aug 20, 2007 5:29 pm
by joncampbell
Thank you for telling me about a registry, that will help me pass information around my framework more easily, but you didn't really answer my question, as a registry utilizes the singleton pattern, you can still answer my question... Do you use a Registry Authentication class (a localized Singleton pattern) for authentication, or do you not, and what do you guys think would be the pros and cons of both sides?

Posted: Mon Aug 20, 2007 5:37 pm
by feyd
A Registry isn't required to be a Singleton.

What kind/form of authentication are you asking about? Generally my authentication is handled by the user login process. It's a method, not a class-in-itself.

Posted: Mon Aug 20, 2007 5:50 pm
by Christopher
"localized singleton" I have never hear of that? What is it? Is it a singleton that internally picks the correct language/locale? That sounds more like a Factory...

By Authentication I mean verifying that the person/computer on the other end of a session proves who they are by some means -- usually with Credentials such as a username and password. Is that how you are using that term?

Posted: Mon Aug 20, 2007 6:08 pm
by joncampbell
By Localized I meant that there was only one singleton class for my entire framework, I have many smaller modules that use the same singleton pattern, like I have one singleton pattern for my session access, so that I know that each visitor will only have one session, no matter where they are.

I was thikning about creating just one class, what authentication I am doing is that I have a case switch on each action that the visitor does, so if the visitor say types example.php?action=edit, that the main app redirects to the file that holds the action of edit. In this file I have a case switch, if the visitor is a guest, a user, or an admin... so I was going to create a singleton class that checked if the user was either a guest, a user, or an admin, and use the method from that singleton before I include the action files.

Posted: Mon Aug 20, 2007 6:14 pm
by Christopher
I think you are using the term "Singleton pattern" in a slightly non-standard way. In general, I would recommend that you try to solve the problems that you mention with a regular object and only resort to a Singleton if you really have a problem with the object being instantiated multiple times. I get the sense that you are using them statically instead of really needing a Singleton.

PS - "motto"

Posted: Tue Aug 21, 2007 7:56 am
by feyd
joncampbell wrote:I was thikning about creating just one class, what authentication I am doing is that I have a case switch on each action that the visitor does, so if the visitor say types example.php?action=edit, that the main app redirects to the file that holds the action of edit. In this file I have a case switch, if the visitor is a guest, a user, or an admin... so I was going to create a singleton class that checked if the user was either a guest, a user, or an admin, and use the method from that singleton before I include the action files.
That sounds more like authorization, not authentication. In the systems I build, authorization generally goes through a access control list where it builds a map for each user. The layers move from general to specific. So, they must first pass the Anonymous/Guest/Registered filter. Then move on to Roles they user is associated with. It eventually trickles to the user level permits.