Bases: object
Sample implementation of an authorization server for development work. This server only implements the basic functionality and isn’t written for high availability or to scale to thousands (or even hundreds) of requests per second. It is mainly for use by developers working on the rest of the system.
The design of the auth system was restricted by a couple of existing systems.
This implementation stores an account name, user name, and password (in plain text!) as well as a corresponding Swift cluster url and account hash. One existing auth system used account, user, and password whereas another used just account and an “API key”. Here, we support both systems with their various, sometimes colliding headers.
The most common use case is by the end user:
Another use case is creating a new account:
A last use case is recreating existing accounts; this is really only useful on a development system when the drives are reformatted quite often but the auth server’s database is retained:
Parameters: |
|
---|
See the etc/auth-server.conf-sample for information on the possible configuration parameters.
Creates an account within the Swift cluster by making a ReST call to each of the responsible account servers.
Parameters: |
|
---|---|
Returns: | False upon failure, otherwise the name of the account within the Swift cluster. |
Handles the create_account call for developers, used to request an account be created both on a Swift cluster and in the auth server database.
This will make ReST requests to the Swift cluster’s account servers to have an account created on its side. The resulting account hash along with the URL to use to access the account, the account name, the user name, and the password is recorded in the auth server’s database. The url is constructed now and stored separately to support changing the configuration file’s default_cluster_url for directing new accounts to a different Swift cluster while still supporting old accounts going to the Swift clusters they were created on.
Parameters: |
|
---|---|
Returns: | False if the create fails, storage url if successful |
Returns a DB API connection instance to the auth server’s SQLite database. This is a contextmanager call to be use with the ‘with’ statement. It takes no parameters.
Handles routing of ReST requests. This handler also logs all requests.
Parameters: |
|
---|
Handles Rest requests from developers to have an account created.
If the HTTP request returns with a 204, then the account was created, and the storage url will be available in the X-Storage-Url header.
Parameters: |
|
---|
Handles ReST requests from developers to have accounts in the Auth system recreated in Swift. I know this is bad ReST style, but this isn’t production right? :)
Parameters: |
|
---|
Handles ReST requests from end users for a Swift cluster url and auth token. This can handle all the various headers and formats that existing auth systems used, so it’s a bit of a chameleon.
X-Auth-User: <account-name>:<user-name>
X-Auth-Key: <password>
The [<account-name>:] is only optional here if the /v1/<account-name>/auth path is used.
X-Storage-Pass: <password>
The (currently) preferred method is to use /v1.0 path and the X-Auth-User and X-Auth-Key headers.
Parameters: |
|
---|
Hanles ReST request from Swift to validate tokens
If the HTTP equest returns with a 204, then the token is valid, and the TTL of the token will be available in the X-Auth-Ttl header.
Parameters: |
|
---|
Removes tokens that have expired from the auth server’s database. This is called by validate_token() and GET() to help keep the database clean.
Recreates the accounts from the existing auth database in the Swift cluster. This is useful on a development system when the drives are reformatted quite often but the auth server’s database is retained.
Returns: | A string indicating accounts and failures |
---|
Tests if the given token is a valid token
Parameters: |
|
---|---|
Returns: | TTL if valid, False otherwise |