Secure Zone Registration Workflow - Constructive Feedback

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…?

All other feedback welcome…

@vlad.z @alex

2 Likes

Another one for the list:

  • 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.
4 Likes

@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.

1 Like

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.

That makes sense if it’s possible.

Hi, we’ll have an update on this from the team next week.

2 Likes

Hi, we have groomed this request and created a feature (it will be released in one of the upcoming sprints)

CRM contacts states improvements

Verification Settings

Add new setting to

  • Settings → Misc → CRM Settings
    • Enable email verification flow
      • Default
        • true
    • When false:
      • Do not send confirmation email
      • On login - do not show validation error if isEmailVerified property of the member is false and just log user in

Registration Logic

Improve registration logic

  • If user submits registration form with correct email and password
    • automatically log user in if isEmailVerified=true or EnableEmailVerificationFlow=false

CRM contacts states indicator

Ability to see state of the CRM contact

  • CRM contact isMember=false (no icon)
  • CRM contact isMember=true AND isEmailVerified=true (blue icon)
  • CRM contact isMember=true AND isEmailVerified=false (grey icon)

DESIGN

Liquid improvement

Extend object of {% component type: “CRMContacts” %}

  • add isMember property to contact object in:
  • add isEmailVerified property to contact object in:

Logic improvement

  • When registration form is submitted

    • set isMember to true when
  • CRM contact edited by admin when new password is set

    • set isMember to true
    • set isEmailVerified to true
  • Add Resend verification button in admin (http://prntscr.com/13e3l2l)

    • show only if isEmailVerified=false

CRM Contacts Advanced Search

  • Add searching and sorting to CRM contacts
    • CRM Type

      • all
      • contacts
      • members
    • Member Type

      • all
      • non-confirmed member
      • confirmed member
  • Remove member type options if CRM Type == contact
  • Advanced filter - rename to Advanced search
  • DESIGN
5 Likes

@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.

1 Like

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.

Hi @SiroccoDigital
CRM contacts states improvements feature will be released in 6.3 release

1 Like

@vlad.z this is wonderful news, thank you.