perl-Apache-AuthCookie

Perl Authentication and Authorization via cookies

*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.

There is no official package available for openSUSE Leap 15.3

Distributions

openSUSE Tumbleweed

openSUSE Leap 15.3

openSUSE Leap 15.2

SUSE SLE-15-SP2

SUSE SLE-15-SP1

Unsupported distributions

The following distributions are not officially supported. Use these packages at your own risk.