volatiletech / authboss

The boss of http auth.
MIT License
3.85k stars 207 forks source link

What is the point of these middlewares? #310

Closed ibraheemdev closed 4 years ago

ibraheemdev commented 4 years ago

There are two middlewares that I don't understand fully:

lock.Middleware: Rejects requests from locked users
confirm.Middleware: Ensures users are confirmed or rejects request
These middlewares are meant to be put on authenticated routes (routes where the user must have an account to access). However, rejecting users from locked or unconfirmed users is already taken care of by the auth events provided by the respective modules Init function: c.Events.Before(authboss.EventAuth, c.PreventAuth) confirm.Middleware
PreventAuth stops the EventAuth from succeeding when a user is not confirmed Middleware ensures that a user is confirmed, or else it will intercept the request and send them to the confirm page
l.Events.Before(authboss.EventAuth, l.BeforeAuth) lock.Middleware
BeforeAuth ensures the account is not locked. Middleware ensures that a user is not locked, or else it will intercept the request and send them to the configured LockNotOK page

There seems to be complete overlap between the middlewares and the before auth events. If a route is already protected by authboss.Middleware, are the lock and confirm middlewares even needed? What is the use case for them?

aarondl commented 4 years ago

The only thing these do is allow you to protect non-login endpoints from unconfirmed or locked users. If you don't use this, a locked user that gets a session (or a user who becomes locked during their session for other reasons) can still access pages as an example.

ibraheemdev commented 4 years ago

Oh, I get it. Because the auth events only protect on login, and once the session is created a locked user can still access pages