This topic is to constructively brainstorm the current Secure Zone workflow.
Currently, the verification process is probably the biggest issue and causing roadblocks for end-users gaining access after registration.
Understandably though, in this age of growing security threats and system vulnerabilities, bypassing this verification process could have a negative impact on the whole platform (much like enforcing ReCaptcha on forms to avoid spam attacks, risking the email server reputation and being marked on blacklists due to a few sites getting abused). So, itâs probably a fact of life that the verification process needs to remain in place and unfortunately, there are always going to be these kinds of user-end roadblocks with this style of account creation (ie; username/password/verification). We just need better tools to help manage it and tweaks to the workflow.
Below is a start to such thoughts for consideration. Please add your own and join the discussion (constructively):
Email verification link:
Ability to resend (both from front-end by the end-user and in admin by the site owner).
â email deliverability is never perfect so there are always going to be cases of these emails going to spam or being blocked. I wonder if there could be an option to use our own email provider (outgoing SMTP servers) to route these, and other system emails, if the AWS mail server is causing problems for a clientâs audience??? or more ways to strengthen email authentication???
Admin button to manually verify a contact (should this send an email notification to the contact?).
Some sort of indicator in CRM showing if contact has been verified (this will help with troubleshooting).
Verification not required for paid zones or if a payment was processed in the form.
Password:
Show hashed password in CRM password field (to indicate a password is set, again this helps with troubleshooting)
Access after Registration:
No matter the amount of messaging and prompts you to add to the registration process informing the user that an email has been sent and verification is required, userâs often just donât read these or follow instructions correctly. We need a smoother workflow for user registration.
Perhaps there could be some sort of pending state for just registered users (prior to verification). So rather than the user being rejected to an unauthorised system page (if they attempt to log in), the CMS recognises their login as a registered, but unverified, user and presents a new system page for this condition.
This way, the page could show better messaging about their âaccess levelâ (and that they need to verify their email) and even present them with other relevant content.
[this pending state could be included in the Liquid member object for custom logic]
Perhaps there could be an optional setting (for sites with less critical security requirements) that allow unverified members to login, but for a limited period (24hrs?). So that the initial verification stage isnât such a roadblock for new users, but bad actors will have limited access. And if verification isnât actioned after 24hrs a system email could be sent to the admin and the user is locked out (until verification workflow is re-triggered).
This seems to be how other systems work that requires email verification. You can still log in, but access/features are limited until you verify.
Other Login Methods:
Are there different login systems that could be implemented that circumvent all this registration/verification process, like âlogin with Google/Facebook/Apple accountâ⌠or some other new authentication/verification techâŚ?
Remember Me / Keep Me Logged in option so that once a user does log in they can remain logged in. Either indefinitely or perhaps an admin setting to control how long a login session can last.
@Adam.Wilson These all seem like great suggestions to reduce authentication friction.
Would having a dedicated server just for sending authentication email reduce the probability of it getting blacklisted?
Re Admin Button to manually verify. I think this is a good idea. I also think that if youâve gotten to the point where you are manually verifying them, you probably donât need to inform them with an email.
Re Other Login Method; This seems like a good solution. This essentially allow offloading verification onto other services, and, I think, could basically eliminate the need to authentication when users sign up on our service. I think this option reduces friction the most. Also, if there is some option for other login methods that donât require re-authentication, it could almost act as a fallback for users who are having issues getting authenticated by email.
Not necessarily a dedicated email server, rather I meant the ability to use the clientâs current email providers SMTP server for sending the email - just like an email client (ie: Outlook) would do.
So youâd enter the outgoing SMTP mail server of the clientâs email provider and the account password so it would basically send directly from that account. No additional SPF authentication/sending on behalf of the domain required.
This would reduce delivery/spam-related issues assuming the clientâs email service is already optimised and fully authorised for sending on their domain.
This would be an alternative setup, only if having delivery issues with AWS or the client just preferred to use their own email server. I wouldnât want this to be the default way of sending system emails.
@vlad.z For the advanced filter, what do you think about incorporating some of the suggestion for custom module filtering design? That way it could be the start of work on that feature as well?
Hi @Alex_B_Centrifuge
It would be better to not merge this additional feature with the current one since it will require additional several grooming sessions that will postpone its release. Custom module filtering is a great public backlog feature that will be groomed based on its votes separately.
RE custom SMTP⌠I see the merit as it would be a solution in some cases. But it would require the client to have smtp active on their domain and knowing the correct details. Thereâs so many ways they could get this wrong. e.g. Their smtp in Outlook may be configured for the default account provided by their ISP, sending on port 25. That wonât work remotely. For those who do have outlook configured to send via their domain email, the smtp may require port 465(ssl) or port 587(tls) or perhaps something else. Given the client is likely already frustrated by the time they attempt implementing this alternative method, presenting them with a solution that has a high chance of failing due to incorrect configuration might not be the best idea.
Very true, and I donât know enough about this to know if itâs even an option or not.
But that aside, I wouldnât expect this to be configured by the client - either the partner, if managing the clientâs email, or their IT department would be the ones consulted on for these settings.
@vlad.z is there any news on when this feature may be released? It have clients that are really struggling to deal with this and we need a much better workflow. It is vital that this is a smooth process for people purchasing and our clients.