NYCPHP Meetup

NYPHP.org

[nycphp-talk] What UserLogin/Auth mechanism do you use ?

Hans Zaunere hans at newyorkphp.com
Sat Dec 13 14:16:53 EST 2003


> > I was wondering what people find most convinient for to do this ?
> > Do you use just php sessions with few own helper functions,
> > PEAR::Auth,other library, or completely homegrown ?

I use my own - pAuth :)  Roles based is the way to go...

> I've been known to roll my own but it sucked and isn't recommended (-:
> 
> Ask Hans about pauth (yo Hans!) -- which btw I started looking at and
> didn't quite grok it, then my attention got diverted away.

Ahh, speaking of which...

There's an older version at http://cvs.nyphp.org/cvsweb.cgi/pauth/ and I
have a much improved version that I'll be committing sometime.  That
said, the pAuth version in CVS should work well as is.

After going through numerous iterations of authorization schemes (not
authentication - that's fairly straightforward) I'm sold on roles based.
At my primary intranet site, the level of granuality for authorization
is huge - numerous projects, each with subtle differences in operation,
permissions and users.  Initially, I took a URL matching approach, which
then failed because different users need to see different aspects of a
page (or even different filesystem files) related to a single URL -
simply, URL -> filesystem translations are troublesome.  I had hacked in
action based authorization, but it quickly became clear that heavy
authorization logic should not be in an umbrella type of model. [1]

The roles model is simple - it simply answers that someone can play a
role (or group of roles) or not.  Determining what to do is left up to
the application.  This offers the ultimate in granuality.  A single page
can offer the logic, or a higher include can for a group of pages.  So
far, pAuth has worked smashingly, and I'm anxious to get the revised
version online.

H

[1] There's an exception to this.  If using an application server type
of environment, where everything is an action to begin with, then it
makes sense to add authorization logic there.  Generally, however, most
sites, especially smaller ones, are just a series of GET and POST
requests, which aren't a concrete way to determine what type of action
is actually occuring.



More information about the talk mailing list