How to Install and Uninstall perl-Apache-AuthCookie Package on openSuSE Tumbleweed
Last updated: November 23,2024
1. Install "perl-Apache-AuthCookie" package
Please follow the step by step instructions below to install perl-Apache-AuthCookie on openSuSE Tumbleweed
$
sudo zypper refresh
Copied
$
sudo zypper install
perl-Apache-AuthCookie
Copied
2. Uninstall "perl-Apache-AuthCookie" package
Please follow the guidelines below to uninstall perl-Apache-AuthCookie on openSuSE Tumbleweed:
$
sudo zypper remove
perl-Apache-AuthCookie
Copied
3. Information about the perl-Apache-AuthCookie package on openSuSE Tumbleweed
Information for package perl-Apache-AuthCookie:
-----------------------------------------------
Repository : openSUSE-Tumbleweed-Oss
Name : perl-Apache-AuthCookie
Version : 3.31-1.10
Arch : noarch
Vendor : openSUSE
Installed Size : 221.4 KiB
Installed : No
Status : not installed
Source package : perl-Apache-AuthCookie-3.31-1.10.src
Upstream URL : https://metacpan.org/release/Apache-AuthCookie
Summary : Perl Authentication and Authorization via cookies
Description :
*Apache::AuthCookie* allows you to intercept a user's first unauthenticated
access to a protected document. The user will be presented with a custom
form where they can enter authentication credentials. The credentials are
posted to the server where AuthCookie verifies them and returns a session
key.
The session key is returned to the user's browser as a cookie. As a cookie,
the browser will pass the session key on every subsequent accesses.
AuthCookie will verify the session key and re-authenticate the user.
All you have to do is write a custom module that inherits from AuthCookie.
Your module is a class which implements two methods:
* 'authen_cred()'
Verify the user-supplied credentials and return a session key. The session
key can be any string - often you'll use some string containing username,
timeout info, and any other information you need to determine access to
documents, and append a one-way hash of those values together with some
secret key.
* 'authen_ses_key()'
Verify the session key (previously generated by 'authen_cred()', possibly
during a previous request) and return the user ID. This user ID will be fed
to '$r->connection->user()' to set Apache's idea of who's logged in.
By using AuthCookie versus Apache's built-in AuthBasic you can design your
own authentication system. There are several benefits.
* 1.
The client doesn't *have* to pass the user credentials on every subsequent
access. If you're using passwords, this means that the password can be sent
on the first request only, and subsequent requests don't need to send this
(potentially sensitive) information. This is known as "ticket-based"
authentication.
* 2.
When you determine that the client should stop using the
credentials/session key, the server can tell the client to delete the
cookie. Letting users "log out" is a notoriously impossible-to-solve
problem of AuthBasic.
* 3.
AuthBasic dialog boxes are ugly. You can design your own HTML login forms
when you use AuthCookie.
* 4.
You can specify the domain of a cookie using PerlSetVar commands. For
instance, if your AuthName is 'WhatEver', you can put the command
PerlSetVar WhatEverDomain .yourhost.com
into your server setup file and your access cookies will span all hosts
ending in '.yourhost.com'.
* 5.
You can optionally specify the name of your cookie using the 'CookieName'
directive. For instance, if your AuthName is 'WhatEver', you can put the
command
PerlSetVar WhatEverCookieName MyCustomName
into your server setup file and your cookies for this AuthCookie realm will
be named MyCustomName. Default is AuthType_AuthName.
* 6.
By default users must satisfy ALL of the 'require' directives. If you want
authentication to succeed if ANY 'require' directives are met, use the
'Satisfy' directive. For instance, if your AuthName is 'WhatEver', you can
put the command
PerlSetVar WhatEverSatisfy Any
into your server startup file and authentication for this realm will
succeed if ANY of the 'require' directives are met.
This is the flow of the authentication handler, less the details of the
redirects. Two REDIRECT's are used to keep the client from displaying the
user's credentials in the Location field. They don't really change
AuthCookie's model, but they do add another round-trip request to the
client.
(-----------------------) +---------------------------------+
( Request a protected ) | AuthCookie sets custom error |
( page, but user hasn't )---->| document and returns |
( authenticated (no ) | FORBIDDEN. Apache abandons |
( session key cookie) ) | current request and creates sub |
(-----------------------) | request for the error document. |<-+
| Error document is a script that | |
| generates a form where the user | |
return | enters authentication | |
^------------------->| credentials (login & password). | |
/ \ False +---------------------------------+ |
/ \ | |
/ \ | |
/ \ V |
/ \ +---------------------------------+ |
/ Pass \ | User's client submits this form | |
/ user's \ | to the LOGIN URL, which calls | |
| credentials |<------------| AuthCookie->login(). | |
\ to / +---------------------------------+ |
\authen_cred/ |
\ function/ |
\ / |
\ / |
\ / +------------------------------------+ |
\ / return | Authen cred returns a session | +--+
V------------->| key which is opaque to AuthCookie.*| |
True +------------------------------------+ |
| |
+--------------------+ | +---------------+
| | | | If we had a |
V | V | cookie, add |
+----------------------------+ r | ^ | a Set-Cookie |
| If we didn't have a session| e |T / \ | header to |
| key cookie, add a | t |r / \ | override the |
| Set-Cookie header with this| u |u / \ | invalid cookie|
| session key. Client then | r |e / \ +---------------+
| returns session key with | n | / pass \ ^
| successive requests | | / session \ |
+----------------------------+ | / key to \ return |
| +-| authen_ses_key|------------+
V \ / False
+-----------------------------------+ \ /
| Tell Apache to set Expires header,| \ /
| set user to user ID returned by | \ /
| authen_ses_key, set authentication| \ /
| to our type (e.g. AuthCookie). | \ /
+-----------------------------------+ \ /
V
(---------------------) ^
( Request a protected ) |
( page, user has a )--------------+
( session key cookie )
(---------------------)
* The session key that the client gets can be anything you want. For
example, encrypted information about the user, a hash of the
username and password (similar in function to Digest
authentication), or the user name and password in plain text
(similar in function to HTTP Basic authentication).
The only requirement is that the authen_ses_key function that you
create must be able to determine if this session_key is valid and
map it back to the originally authenticated user ID.
-----------------------------------------------
Repository : openSUSE-Tumbleweed-Oss
Name : perl-Apache-AuthCookie
Version : 3.31-1.10
Arch : noarch
Vendor : openSUSE
Installed Size : 221.4 KiB
Installed : No
Status : not installed
Source package : perl-Apache-AuthCookie-3.31-1.10.src
Upstream URL : https://metacpan.org/release/Apache-AuthCookie
Summary : Perl Authentication and Authorization via cookies
Description :
*Apache::AuthCookie* allows you to intercept a user's first unauthenticated
access to a protected document. The user will be presented with a custom
form where they can enter authentication credentials. The credentials are
posted to the server where AuthCookie verifies them and returns a session
key.
The session key is returned to the user's browser as a cookie. As a cookie,
the browser will pass the session key on every subsequent accesses.
AuthCookie will verify the session key and re-authenticate the user.
All you have to do is write a custom module that inherits from AuthCookie.
Your module is a class which implements two methods:
* 'authen_cred()'
Verify the user-supplied credentials and return a session key. The session
key can be any string - often you'll use some string containing username,
timeout info, and any other information you need to determine access to
documents, and append a one-way hash of those values together with some
secret key.
* 'authen_ses_key()'
Verify the session key (previously generated by 'authen_cred()', possibly
during a previous request) and return the user ID. This user ID will be fed
to '$r->connection->user()' to set Apache's idea of who's logged in.
By using AuthCookie versus Apache's built-in AuthBasic you can design your
own authentication system. There are several benefits.
* 1.
The client doesn't *have* to pass the user credentials on every subsequent
access. If you're using passwords, this means that the password can be sent
on the first request only, and subsequent requests don't need to send this
(potentially sensitive) information. This is known as "ticket-based"
authentication.
* 2.
When you determine that the client should stop using the
credentials/session key, the server can tell the client to delete the
cookie. Letting users "log out" is a notoriously impossible-to-solve
problem of AuthBasic.
* 3.
AuthBasic dialog boxes are ugly. You can design your own HTML login forms
when you use AuthCookie.
* 4.
You can specify the domain of a cookie using PerlSetVar commands. For
instance, if your AuthName is 'WhatEver', you can put the command
PerlSetVar WhatEverDomain .yourhost.com
into your server setup file and your access cookies will span all hosts
ending in '.yourhost.com'.
* 5.
You can optionally specify the name of your cookie using the 'CookieName'
directive. For instance, if your AuthName is 'WhatEver', you can put the
command
PerlSetVar WhatEverCookieName MyCustomName
into your server setup file and your cookies for this AuthCookie realm will
be named MyCustomName. Default is AuthType_AuthName.
* 6.
By default users must satisfy ALL of the 'require' directives. If you want
authentication to succeed if ANY 'require' directives are met, use the
'Satisfy' directive. For instance, if your AuthName is 'WhatEver', you can
put the command
PerlSetVar WhatEverSatisfy Any
into your server startup file and authentication for this realm will
succeed if ANY of the 'require' directives are met.
This is the flow of the authentication handler, less the details of the
redirects. Two REDIRECT's are used to keep the client from displaying the
user's credentials in the Location field. They don't really change
AuthCookie's model, but they do add another round-trip request to the
client.
(-----------------------) +---------------------------------+
( Request a protected ) | AuthCookie sets custom error |
( page, but user hasn't )---->| document and returns |
( authenticated (no ) | FORBIDDEN. Apache abandons |
( session key cookie) ) | current request and creates sub |
(-----------------------) | request for the error document. |<-+
| Error document is a script that | |
| generates a form where the user | |
return | enters authentication | |
^------------------->| credentials (login & password). | |
/ \ False +---------------------------------+ |
/ \ | |
/ \ | |
/ \ V |
/ \ +---------------------------------+ |
/ Pass \ | User's client submits this form | |
/ user's \ | to the LOGIN URL, which calls | |
| credentials |<------------| AuthCookie->login(). | |
\ to / +---------------------------------+ |
\authen_cred/ |
\ function/ |
\ / |
\ / |
\ / +------------------------------------+ |
\ / return | Authen cred returns a session | +--+
V------------->| key which is opaque to AuthCookie.*| |
True +------------------------------------+ |
| |
+--------------------+ | +---------------+
| | | | If we had a |
V | V | cookie, add |
+----------------------------+ r | ^ | a Set-Cookie |
| If we didn't have a session| e |T / \ | header to |
| key cookie, add a | t |r / \ | override the |
| Set-Cookie header with this| u |u / \ | invalid cookie|
| session key. Client then | r |e / \ +---------------+
| returns session key with | n | / pass \ ^
| successive requests | | / session \ |
+----------------------------+ | / key to \ return |
| +-| authen_ses_key|------------+
V \ / False
+-----------------------------------+ \ /
| Tell Apache to set Expires header,| \ /
| set user to user ID returned by | \ /
| authen_ses_key, set authentication| \ /
| to our type (e.g. AuthCookie). | \ /
+-----------------------------------+ \ /
V
(---------------------) ^
( Request a protected ) |
( page, user has a )--------------+
( session key cookie )
(---------------------)
* The session key that the client gets can be anything you want. For
example, encrypted information about the user, a hash of the
username and password (similar in function to Digest
authentication), or the user name and password in plain text
(similar in function to HTTP Basic authentication).
The only requirement is that the authen_ses_key function that you
create must be able to determine if this session_key is valid and
map it back to the originally authenticated user ID.