volatiletech / authboss Goto Github PK

Make them have context

At least need a 500 page

Let's find out ^_^

I think it shouldn't be rendering tmpl.Name() but just the name of the layout, which we'd need to save somehow.

How do users reset their password in a normal flow? Do they really have to go through recover and getting e-mails etc? Or are we leaving all user editing up to the other person, who then now has to know about authboss semantics such as if you update a password it should invalidate all remember me tokens, and bcrypt the password with the correct configured strength.

Responsible for:

• Interrupting the flow of User Creation to insert this validation step.
• Sending an e-mail to the half-registered user.
• Accepting a validation token, finding the associated user, and marking him as fully registered user.

A generic approach to storing and retrieving the information we need. Each one of these things must be separate but hopefully use the same standard interface.

User information (email, password, auth tokens, etc etc)
Cookie information (some people store these in DB, in files, etc)
Secrets

We could also provide some common storage implementations like Go's sql.DB for sqlite3, mysql and postgres and keep them in a subpackage like /storers. Mongo can be in there too ^_^

This requires us to bail ship on parallel testing.

Both should be overridden using the same template system for web views. This makes the overall integration experience easier.

TokenStorer, RecoverStorer, and ConfrmStorer should be moved from storer.go to their respective modules.

This will allow use to work with SQLDriver values like NullString and NullTime

Locks out users who try to fail authentication. Should accept parameters for reset times, number of failures, duration of lockout etc.

• Does remember me create a session or is it the session
• When remember-me-started-session end should the user session end?

Allows users to reset their passwords, which will create a unique token for the password reset request, send it to the e-mail registered, and allow a user to reset their password with use of the token.

A generic approach to storing and retrieving the information we need. Each one of these things must be separate but hopefully use the same standard interface.

User information (email, password, auth tokens, etc etc)
Cookie information (some people store these in DB, in files, etc)
Secrets

We could also provide some common storage implementations like Go's sql.DB for sqlite3, mysql and postgres and keep them in a subpackage like /storers. Mongo can be in there too ^_^

• Authenticates using Username + Password
• Stores some sort of persistence or has an interface to allow persistence of the session.

When requested, a user who is signing in will be remembered by a unique token that's given to the user.

Instead of Authenticating with email & password, the token is used, it is deleted and a new one is given.

Care must be given to flagging the logged in session as not half-authed. To disallow entry to sensitive areas without full-authentication.

Does this really need PrimaryID AND Email? Just not sure.

Sets an expiry on the user's log in sessions beyond their session cookies.

Why does this exist? Shouldn't it always just refresh the page with validation errors etc?

Remember module has a comparison of hashed values (technically a password).
So does Recovery

Session Vars and User Var lookups (should return err if nil|len=0)
str, err := User.StringErr()
if err != nil {
return err // err is authboss.AttributeErr
}

authboss.ClientDataErr // session & cookie store helpers should return this :D

Redirect (on success) -> Leave it
func FlashRedirect(w, "/", "", "")
func Redirect(w, "/")

Redirect (on failure) -> Get router to handle this as en error type
func RedirectErr(w, r, "/", "login successful", "") (flash messages, go to endpoint)

Render things that handle errors better.
data = data.Merge("username", username).FlashSuccess(ctx, "lol")
func views.Render(w, r, templName, data) err (authboss.RenderErr)

Tidy up callbacks & handler (both need to return error, callbacks need to stop execution with ok, not error)

clean up e-mailers in confirm & recover to use same code

Does user/email/password validation.

How do we handle expired tokens on the Storer side of the equation.

RememberMe

• GetUser
• AfterSuccess

Expire

• BeforeAuth
• GetUser

Lock

• BeforeAuth
• GetUser

Register

Confirm

• BeforeAuth
• AfterRegister

Auth

• GetUser
• AfterSucess
• AfterFailure

Validate

• BeforeRegister

Responsible for:

• Creation of Users