5.7.4. Bugzilla::Auth¶
5.7.4.1. NAME¶
- Bugzilla::Auth - An object that authenticates the login credentials for
- a user.
5.7.4.2. DESCRIPTION¶
Handles authentication for Bugzilla users.
Authentication from Bugzilla involves two sets of modules. One set is used to obtain the username/password (from CGI, email, etc), and the other set uses this data to authenticate against the datasource (the Bugzilla DB, LDAP, PAM, etc.).
Modules for obtaining the username/password are subclasses of Bugzilla::Auth::Login, and modules for authenticating are subclasses of Bugzilla::Auth::Verify.
5.7.4.3. AUTHENTICATION ERROR CODES¶
Whenever a method in the Bugzilla::Auth
family fails in some way,
it will return a hashref containing at least a single key called failure
.
failure
will point to an integer error code, and depending on the error
code the hashref may contain more data.
The error codes are explained here below.
AUTH_NODATA
¶
Insufficient login data was provided by the user. This may happen in several cases, such as cookie authentication when the cookie is not present.
AUTH_ERROR
¶
An error occurred when trying to use the login mechanism.
The hashref will also contain an error
element, which is the name
of an error from template/en/default/global/code-error.html
--
the same type of error that would be thrown by
Bugzilla::Error::ThrowCodeError.
The hashref *may* contain an element called details
, which is a hashref
that should be passed to Bugzilla::Error::ThrowCodeError as the
various fields to be used in the error message.
AUTH_LOGINFAILED
¶
An incorrect username or password was given.
The hashref may also contain a failure_count
element, which specifies
how many times the account has failed to log in within the lockout
period (see AUTH_LOCKOUT). This is used to warn the user when
they are getting close to being locked out.
AUTH_NO_SUCH_USER
¶
This is an optional more-specific version of AUTH_LOGINFAILED
.
Modules should throw this error when they discover that the
requested user account actually does not exist, according to them.
That is, for example, Bugzilla::Auth::Verify::LDAP would throw this if the user didn't exist in LDAP.
The difference between AUTH_NO_SUCH_USER
and AUTH_LOGINFAILED
should never be communicated to the user, for security reasons.
AUTH_DISABLED
¶
The user successfully logged in, but their account has been disabled.
Usually this is throw only by Bugzilla::Auth::login
.
AUTH_LOCKOUT
¶
The user's account is locked out after having failed to log in too many times within a certain period of time (as specified by Bugzilla::Constants/LOGIN_LOCKOUT_INTERVAL).
The hashref will also contain a user
element, representing the
Bugzilla::User whose account is locked out.
5.7.4.4. LOGIN TYPES¶
The login
function (below) can do different types of login, depending
on what constant you pass into it:
LOGIN_OPTIONAL
¶
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.
LOGIN_NORMAL
¶
A login may or may not be required, depending on the setting of the requirelogin parameter. This is the default if you don't specify a type.
LOGIN_REQUIRED
¶
A login is always required to access this data.
5.7.4.5. METHODS¶
These are methods that can be called on a Bugzilla::Auth
object
itself.
Login¶
login($type)
- Description: Logs a user in. For more details on how this works
- internally, see the section entitled "STRUCTURE."
Params: $type - One of the Login Types from above. Returns: An authenticated
Bugzilla::User
. Or, if the type wasnotLOGIN_REQUIRED
, then we return an emptyBugzilla::User
if no login data was passed in.
Info Methods¶
These are methods that give information about the Bugzilla::Auth object.
can_change_password
- Description: Tells you whether or not the current login system allows
- changing passwords.
Params: None Returns:
true
if users and administrators should be allowed tochange passwords,false
otherwise.
can_login
- Description: Tells you whether or not the current login system allows
- users to log in through the web interface.
Params: None Returns:
true
if users can log in through the web interface,false
otherwise.
can_logout
- Description: Tells you whether or not the current login system allows
- users to log themselves out.
Params: None Returns:
true
if users can log themselves out,false
otherwise.If a user isn't logged in, we always returnfalse
.
user_can_create_account
- Description: Tells you whether or not users are allowed to manually create
- their own accounts, based on the current login system in use. Note that this doesn't check the
createemailregexp
parameter--you have to do that by yourself in your code.Params: None Returns:
true
if users are allowed to create new Bugzilla accounts,false
otherwise.
extern_id_used
Description: Whether or not current login system uses extern_id.
can_change_email
- Description: Whether or not the current login system allows users to
- change their own email address.
Params: None Returns:
true
if users can change their own email address,false
otherwise.
login_token
- Description: If a login token was used instead of a cookie then this
- will return the current login token data such as user id and the token itself.
Params: None Returns: A hash containing
login_token
anduser_id
.
5.7.4.6. STRUCTURE¶
This section is mostly interesting to developers who want to implement
a new authentication type. It describes the general structure of the
Bugzilla::Auth family, and how the login
function works.
A Bugzilla::Auth
object is essentially a collection of a few other
objects: the "Info Getter," the "Verifier," and the "Persistence
Mechanism."
They are used inside the login
function in the following order:
The Info Getter¶
This is a Bugzilla::Auth::Login
object. Basically, it gets the
username and password from the user, somehow. Or, it just gets enough
information to uniquely identify a user, and passes that on down the line.
(For example, a user_id
is enough to uniquely identify a user,
even without a username and password.)
Some Info Getters don't require any verification. For example, if we got
the user_id
from a Cookie, we don't need to check the username and
password.
If an Info Getter returns only a user_id
and no username/password,
then it MUST NOT require verification. If an Info Getter requires
verfication, then it MUST return at least a username
.
The Verifier¶
This verifies that the username and password are valid.
It's possible that some methods of verification don't require a password.
The Persistence Mechanism¶
This makes it so that the user doesn't have to log in on every page. Normally this object just sends a cookie to the user's web browser, as that's the most common method of "login persistence."
Other Things We Do¶
After we verify the username and password, sometimes we automatically create an account in the Bugzilla database, for certain authentication types. We use the "Account Source" to get data about the user, and create them in the database. (Or, if their data has changed since the last time they logged in, their data gets updated.)
The $login_data
Hash¶
All of the Bugzilla::Auth::Login
and Bugzilla::Auth::Verify
methods take an argument called $login_data
. This is basically
a hash that becomes more and more populated as we go through the
login
function.
All Bugzilla::Auth::Login
and Bugzilla::Auth::Verify
methods
also *return* the $login_data
structure, when they succeed. They
may have added new data to it.
For all Bugzilla::Auth::Login
and Bugzilla::Auth::Verify
methods,
the rule is "you must return the same hashref you were passed in." You can
modify the hashref all you want, but you can't create a new one. The only
time you can return a new one is if you're returning some error code
instead of the $login_data
structure.
Each Bugzilla::Auth::Login
or Bugzilla::Auth::Verify
method
explains in its documentation which $login_data
elements are
required by it, and which are set by it.
Here are all of the elements that *may* be in $login_data
:
user_id
A Bugzillauser_id
that uniquely identifies a user.
username
The username that was provided by the user.
bz_username
The username of this user inside of Bugzilla. Sometimes this differs fromusername
.
password
The password provided by the user.
realname
The real name of the user.
extern_id
Some string that uniquely identifies the user in an external account source. If this
extern_id
already exists in the database with a different username, the username will be *changed* to be the username specified in this$login_data
.That is, let's my extern_id is
mkanat
. I already have an account in Bugzilla with the username ofmkanat@foo.com
. But this time, when I log in, I have an extern_id ofmkanat
and ausername
ofmkanat@bar.org
. So now, Bugzilla will automatically change my username tomkanat@bar.org
instead ofmkanat@foo.com
.
user
A Bugzilla::User object representing the authenticated user. Note thatBugzilla::Auth::login
may modify this object at various points.
This documentation undoubtedly has bugs; if you find some, please file them here.