Re: Competitive Package: Auth

From: Date: Thu, 12 Sep 2002 08:09:23 +0000
Subject: Re: Competitive Package: Auth
References: 1 2 3  Groups: php.pear.dev php.pear.general 
Request: Send a blank email to pear-dev+get-9016@lists.php.net to get a copy of this message
btw this Auth package is also available as a PEAR-compatible package, simply download the 'Auth as PEAR package' from here:
    http://sourceforge.net/project/showfiles.php?group_id=46153
and install it using 'pear install Auth' Wolfram Wolfram Kriesing wrote:
Alan Knowles wrote:
Can you expain how it differs from the current Auth, -
see below eg. can it behave as a straight replacement eg. could these features be added to the current Auth Package? i was talking to martin in this point a long time ago, the problem was that we couldnt agree on how ... or is it really just focused on File permisions? i think that's answered by the section * standard auth mode Difference to PEAR::Auth in short -------- * easy to use and very fast to migrate an application to use it * autoAuth, no auth-check on every page needed * standard auth mode * you can use multiple instances on a page * the session-array name is not fixed and has a cryptic name * setting/getting (user)data to be able to retreive them from the auth * setting the loginDataSource * numerous authentication sources the long version ---------------- * easy to use and very fast to migrate an application to use it an usage example follows. and what i like about it is that i never have to worry about the auth anymore ................................................ require_once('Auth/Auth.php'); $options = array(
     'expire'        =>  5*60*60,    // expire after 5 hours
     'protectRoot'   =>  $config->applPathPrefix.'/modules',
     'dontProtect'   =>  '*.css.*',
     'loginPage'     =>  'user/login.php',
     'errorPage'     =>  '/user/login.php?loginFailed=true',
     'defaultPage'   =>  '/user/login.php',
     'digest'        =>  'none'
); $auth = Auth::setup( 'IMAP' ,
                     'pop3/notls://alice.unix.vp:110' , $options );
if( Auth::isError($auth) )
    print_r($auth);
............................................... thats all the code i need for including an authentication in my application. and the only other interaction with the auth class is actually getting the user id by calling $auth->getData('user_id') that's it :-) * autoAuth, no auth-check on every page needed the package has a mode (called 'autoAuth') that allows you to specify the files/directories that shall be protected, this way its not necessary to include a check on every site that needs authentication. example: you only want to protect the admin area on your site, the admin area is avialable by http://yoursite/admin and the directory structure maps to the structure in the web, so
http://yoursite/admin     =>  /usr/local/httpd/htdocs/admin
http://yoursite/index.php => /usr/local/httpd/htdocs/index.php knowing that for one and the second is: you need to have the application include a file on every page, i.e. via auto_prepend. this is mostly the case, since all the applications i know have a config file, which specifies the db-DSN and all the stuff that is global to the application. inside this file you put the instanciating of the Auth class and it automatically protects the pages by redirecting to the 'loginPage' which is assumed to be in the 'protectRoot' and is of course not protected. in the case of a failure it redirects to the 'errorPage', or the 'expirePage' * standard auth mode sure you can also leave all the pages unprotected or even turn the autoAuth mode off and you can check the proper authentication via 'isLoggedIn', and let the user log in/out via the method 'login' or 'logout' * you can use multiple instances on a page you can use multiple instances on a page, which i needed once. and the session data wont overwrite each other. i.e. if i need an authentication for the admin area which for some reason should not have anything to do with the user-area auth. so you need two authentication instances (which may by also check against different sources, one against LDAP, the other against a DB). one that checks the admin stuff, the other that checks the normal user auth and if that is inside the same application those two auths better dont overwrite each other's session data. so when i login as 'cain' on the admin site and as 'cain' on the user site those authentications should not overwrite one another, since they might have different things to save in the session. (i am not sure but i think PEAR::Auth would fail here) * the session-array name is not fixed and has a cryptic name by default the auth-data are written into an array with a given prefix
     'sessionArrayPrefix' default is '_auth'
and a hash over the options, that are passed to the auth-instance is added, so that the session-array name might result in something like this '_auth23892k3jh42jztg23lkhj' which has no importance to the user at all anyway. BTW this also enables the usage of multiple instances in one appl
* setting/getting (user)data to be able to retreive them from the auth when authenticating against a DB for example, all the data from the DB-row that matched the username and password combination will be made available if desired so. simply by
    $auth->getData('columnName')
you can get the data. this can i.e. also be used for access control. if the DB-row returns the group, accesslevel or whatever you simply retreive it by
    $auth->getData('group')             OR
    $auth->getData('accesslevel')       OR
    $auth->getData('permission')
and the data are available in your appl. you can of course also add data to the auth data, which you can later retreive via getData()
$auth->setData('myData',$myValue) and get it via $auth->getData('myData'). * setting the loginDataSource usually the auth data such as login and password are passed to the auth via POST, but you can also define that to be something else. simply by setting the 'loginDataSource' which defaults to 'HTTP_POST_VARS'. * authentication sources now it supports DB, LDAP, NIS, IMAP, XMLRPC, Files, MemoryQuest (a special one) i guess there is more that is different to PEAR::Auth, i will post know when it comes to my mind again :-)
-- Wolfram ... translating template engine .... http://sf.net/projects/simpletpl ... authentication system .... http://sf.net/projects/auth

« previous php.pear.dev (#9016) next »