AuthWeb.AuthController (auth v1.6.6)
Defines AuthController and all functions for authenticaiton
Link to this section Summary
Functions
get_client_secret_from_state/1 gets the client_id from state,
attempts to decode_decrypt it and then look it up in apikeys
if it finds the corresponding client_secret it returns the client_secret.
All other failure conditions return a 0 (zero) which results in a 401.
github_auth/2 handles the callback from GitHub Auth API redirect.
google_handler/2 handles the callback from Google Auth API redirect.
handler/3 responds to successful auth requests.
if the state is defined, redirect to it.
login_register_handler/2 is a hybrid of traditional registration and login.
If the person has already registered, we treat it as a login attempt and
present them with a password field/form to complete.
If the person does not exist (or has not yet verified their email address),
we show them a welcome screen informing them that a verification email
was sent to their address. When they click it they will see a password (reset)
form where they can define a new password for their account.
logout/2 logs the person out of their session and destroys cookie.
make_verify_link/3 creates a verfication link that gets included
in the email we send to people to verify their email address.
The person.id is encrypted and base58 encoded to avoid anyone verifying
a different person's email. (not that anyone would do that, right? ;-)
We include the original state (HTTP referer) so that the request can be
redirected back to the desired page on successful verification.
password_create/2 is called when a new person is registering with email
and is defining a password for the first time.
Note: at present we are not enforcing any rules for password strength/length.
Thinking of doing these checks as progressive enhancement in Browser.
see
password_prompt/2 handles all requests to verify a password for a person.
If the pasword is verified (using Argon2.verify_pass), redirect to their
desired page. If the password is invalid reset & re-render the form.
redirect_or_render/3 does what it's name suggests,
redirects if the state (HTTP referer) is defined
or renders the default :welcome template.
If the auth_client_id is undefined or invalid,
render the unauthorized/1 401.
Link to this section Functions
add_jwt_url_param(person, sid, state, client_secret)
admin(conn, params)
append_client_id(referer, client_id)
client_id_valid?(client_id, conn)
error(conn, msg, status)
get_app_id(state)
get_client_id_from_state(state)
get_client_secret(client_id, state)
get_client_secret_from_state(state)
get_client_secret_from_state/1 gets the client_id from state,
attempts to decode_decrypt it and then look it up in apikeys
if it finds the corresponding client_secret it returns the client_secret.
All other failure conditions return a 0 (zero) which results in a 401.
get_referer(conn)
github_handler(conn, map)
github_auth/2 handles the callback from GitHub Auth API redirect.
google_handler(conn, map)
google_handler/2 handles the callback from Google Auth API redirect.
handler(conn, person, state)
handler/3 responds to successful auth requests.
if the state is defined, redirect to it.
index(conn, params)
login_register_handler(conn, params)
login_register_handler/2 is a hybrid of traditional registration and login.
If the person has already registered, we treat it as a login attempt and
present them with a password field/form to complete.
If the person does not exist (or has not yet verified their email address),
we show them a welcome screen informing them that a verification email
was sent to their address. When they click it they will see a password (reset)
form where they can define a new password for their account.
logout(conn, params)
logout/2 logs the person out of their session and destroys cookie.
make_verify_link(conn, person, state)
make_verify_link/3 creates a verfication link that gets included
in the email we send to people to verify their email address.
The person.id is encrypted and base58 encoded to avoid anyone verifying
a different person's email. (not that anyone would do that, right? ;-)
We include the original state (HTTP referer) so that the request can be
redirected back to the desired page on successful verification.
not_found(conn, msg)
password_create(conn, params)
password_create/2 is called when a new person is registering with email
and is defining a password for the first time.
Note: at present we are not enforcing any rules for password strength/length.
Thinking of doing these checks as progressive enhancement in Browser.
see:
password_prompt(conn, params)
password_prompt/2 handles all requests to verify a password for a person.
If the pasword is verified (using Argon2.verify_pass), redirect to their
desired page. If the password is invalid reset & re-render the form.
redirect_or_render(conn, person, state)
redirect_or_render/3 does what it's name suggests,
redirects if the state (HTTP referer) is defined
or renders the default :welcome template.
If the auth_client_id is undefined or invalid,
render the unauthorized/1 401.