From 8a06f991edf359f9ffeb53cc57173023c44d9644 Mon Sep 17 00:00:00 2001 From: "kiko%async.com.br" <> Date: Sat, 27 Mar 2004 09:28:29 +0000 Subject: Fix for bug 226764: Move InvalidateLogins into Bugzilla::Auth::CGI. Consolidates the logout code into Bugzilla::Auth::CGI, and provides simple front-end wrappers in Bugzilla.pm for use in the CGIs we have. r=bbaetz, joel; a=justdave. Adds a set of constants to the logout() API which allow specifying "how much" we should log out -- all sessions, the current session, or all sessions but the current one. Fixes callsites to use this new API; cleans and documents things a bit while we're at it. Part I in the great COOKIE apocalypse. --- Bugzilla/Auth.pm | 114 ++++++++++++++++++++++++++++++++++++------------------- 1 file changed, 74 insertions(+), 40 deletions(-) (limited to 'Bugzilla/Auth.pm') diff --git a/Bugzilla/Auth.pm b/Bugzilla/Auth.pm index 22c2fc561..dcea8189a 100644 --- a/Bugzilla/Auth.pm +++ b/Bugzilla/Auth.pm @@ -73,15 +73,18 @@ Bugzilla::Auth - Authentication handling for Bugzilla users Handles authentication for Bugzilla users. -Authentication from Bugzilla involves two sets of modules. One set is used to -obtain the data (from CGI, email, etc), and the other set uses this data to -authenticate against the datasource (the Bugzilla DB, LDAP, cookies, etc). +Authentication from Bugzilla involves two sets of modules. One set is +used to obtain the data (from CGI, email, etc), and the other set uses +this data to authenticate against the datasource (the Bugzilla DB, LDAP, +cookies, etc). -The handlers for the various types of authentication (DB/LDAP/cookies/etc) -provide the actual code for each specific method of authentication. +The handlers for the various types of authentication +(DB/LDAP/cookies/etc) provide the actual code for each specific method +of authentication. -The source modules (currently, only L -then use those methods to do the authentication. +The source modules (currently, only +L) then use those methods to do +the authentication. I itself inherits from the default authentication handler, identified by the I param. @@ -96,16 +99,16 @@ authentication or login modules. =item C Given an ip address, this returns the associated network address, using -C at the netmask. This can be used to obtain data in -order to restrict weak authentication methods (such as cookies) to only some -addresses. +C as the netmask. This can be used to obtain data +in order to restrict weak authentication methods (such as cookies) to +only some addresses. =back =head1 AUTHENTICATION -Authentication modules check a users's credentials (username, password, etc) to -verify who the user is. +Authentication modules check a user's credentials (username, password, +etc) to verify who the user is. =head2 METHODS @@ -113,19 +116,21 @@ verify who the user is. =item C -This method is passed a username and a password, and returns a list containing -up to four return values, depending on the results of the authentication. +This method is passed a username and a password, and returns a list +containing up to four return values, depending on the results of the +authentication. The first return value is one of the status codes defined in -L and described below. The rest of -the return values are status code-specific and are explained in the status -code descriptions. +L and described below. The +rest of the return values are status code-specific and are explained in +the status code descriptions. =over 4 =item C -Authentication succeeded. The second variable is the userid of the new user. +Authentication succeeded. The second variable is the userid of the new +user. =item C @@ -162,41 +167,52 @@ information. =item C -The user successfully logged in, but their account has been disabled. The -second argument in the returned array is the userid, and the third is some -text explaining why the account was disabled. This text would typically come -from the C field in the C table. Note that this -argument is a string, not a tag. +The user successfully logged in, but their account has been disabled. +The second argument in the returned array is the userid, and the third +is some text explaining why the account was disabled. This text would +typically come from the C field in the C table. +Note that this argument is a string, not a tag. =back =item C This determines if the user's account details can be modified. If this -method returns a C value, then accounts can be created and modified -through the Bugzilla user interface. Forgotten passwords can also be -retrieved through the L. +method returns a C value, then accounts can be created and +modified through the Bugzilla user interface. Forgotten passwords can +also be retrieved through the L. =back =head1 LOGINS -A login module can be used to try to log in a Bugzilla user in a particular -way. For example, L logs in users -from CGI scripts, first by trying database authentication against the -Bugzilla C table, and then by trying cookies as a fallback. +A login module can be used to try to log in a Bugzilla user in a +particular way. For example, L +logs in users from CGI scripts, first by using form variables, and then +by trying cookies as a fallback. -A login module consists of a single method, C, which takes a C<$type> -argument, using constants found in C. +The login interface consists of the following methods: + +=item C, which takes a C<$type> argument, using constants found in +C. + +The login method may use various authentication modules (described +above) to try to authenticate a user, and should return the userid on +success, or C on failure. + +When a login is required, but data is not present, it is the job of the +login method to prompt the user for this data. + +The constants accepted by C include the following: =over 4 =item C -A login is never required to access this data. Attempting to login is still -useful, because this allows the page to be personalised. Note that an -incorrect login will still trigger an error, even though the lack of a login -will be OK. +A login is never required to access this data. Attempting to login is +still useful, because this allows the page to be personalised. Note that +an incorrect login will still trigger an error, even though the lack of +a login will be OK. =item C @@ -209,12 +225,30 @@ A login is always required to access this data. =back -The login module uses various authentication modules to try to authenticate -a user, and returns the userid on success, or C on failure. +=item C, which takes a C argument for the user +being logged out, and an C<$option> argument. Possible values for +C<$option> include: + +=over 4 + +=item C -When a login is required, but data is not present, it is the job of the login -module to prompt the user for this data. +Log out the user and invalidate his currently registered session. + +=item C + +Log out the user, and invalidate all sessions the user has registered in +Bugzilla. + +=item C + +Invalidate all sessions the user has registered excluding his current +session; this option should leave the user logged in. This is useful for +user-performed password changes. + +=back =head1 SEE ALSO L, L, L + -- cgit v1.2.3-24-g4f1b