Better support for typical email confirmation flows

[rbren]

First off - thanks for building and supporting this package!

I struggled a bit to implement a reasonable email confirmation flow. I documented my eventual solution in the wiki

What I'd like to happen is this:

• User signs up
• User sees a page that says we've sent a confirmation email to foo@bar.com
• User can still access some parts of the site before confirmation, but others are blocked off

Ideally, I'd be able to implement this flow just by not using confirm.Middleware, and creating my own middleware. But AB registers its confirm checks in the confirm.Init method, making it impossible to override.

Two things that would need to change:

• AB should still start a session upon registration even if confirm is enabled
• AB should only check user.GetConfirmed() == true in the middleware (which it does now) and not as part of a Before(authboss.EventAuth) check

[aarondl]

I think the best course of action here is to create a second confirm module that works as you're specifying. That should allow the flexibility we need for this functionality.

[rbren]

The solution I documented in the wiki is working well, so I'll probably stick with that for now.

I'd suggest leaving this open, maybe for the next major version. The needs here are pretty standard for a typical email confirmation flow. Namely:

• rendering a confirmation page with something like an email has been sent to you@example.com
• resending the confirmation email if the user clicks a link
• showing the user as logged in but unconfirmed
• restricting access to parts of the site based on confirm status

[aarondl]

@rbren I think that you're making an assumption that all sites want to allow partial access to unconfirmed users. In the main site that I use authboss for as an example, this is not the case. Users must be fully confirmed before they have access to anything.

Given that the requirements are different there's three courses of action:

1. We add configuration to the current confirm module to be able to work in both ways.
2. We write a new confirm module to support the workflow you're talking about as a drop-in replacement.
3. We continue to have people implement it as you have done so in the wiki.

The one option that is not on the table is to remove that which is there today and the technically more secure option in favor of the workflow that you're suggesting, since it is in use currently and working as desired. I'm not sure given what you've written thus far if you're suggesting this course of action or not, but I just wanted to explicitly call it out as not desirable.

That said it's definitely a fine idea as you're right many sites could use that sort of a workflow. It could find a place in authboss. Authboss is currently in maintenance mode so I won't be adding any new features (like this) but if there are willing contributors it's definitely possible.