[SOLVED] Things to look out for in the registration process

[sammyskills]

Hi guys,

I've been thinking about this for a while now, and I think it's best I share with you all.

During registration (when an email action is enabled), CI-Shield doesn't follow the commonly used process of sending a verification link which can be clicked from the user's email. While I think this is great, I think there are a few flaws we need to look at:

1. After a successful registration, users are redirected to the auth/a/show page. What happens when the activation email is not received by the user immediately, maybe due to poor network, etc, can the user retrieve the token page after the page is exited and session/cookie is deleted?

Here's a use-case scenario:

• User A registers but doesn't receive the activation email until after 4 hours due to poor network or maybe got distracted by something else
• User A turns off their device or simply closes the current browser which deletes the current session/cookie that makes the token verification page to show

At this point, when User A decides to come back to the website after retrieving the activation code from their email (maybe with another browser), they are presented with the login page or registration page and the token verification page is no longer accessible.
How can the user verify/activate their account?

2. I think there should be a way to resend the activation code, just in case a user doesn't get it at first trial.

[MGatner]

I think resending an activation code is an important feature, especially because identities are unique in the database so once a registration is started a user may not start over if the activation fails.

[pixobit]

The time limit is important, because if the email doesn't get delivered right away, the user might resend it again right away, this is common behavior, now if you get the first email, and the 2nd one is delayed, you will see it is not working anymore, so you would resend it again, but now you get the 2nd email, and so on.
I'm saying this, because I did experience this before on some site, and it was frustrating. A time limit would avoid this scenario.

[kenjis]

Do you mean all codes should be valid if they are not expired?
It would certainly be more usable.

[pixobit]

You're right, that would be even more convenient

[warcooft]

The time limit is important, because if the email doesn't get delivered right away, the user might resend it again right away, this is common behavior, now if you get the first email, and the 2nd one is delayed, you will see it is not working anymore, so you would resend it again, but now you get the 2nd email, and so on.
I'm saying this, because I did experience this before on some site, and it was frustrating. A time limit would avoid this scenario.

This scenario often occurs in the field and yes it is a nightmare. is there a plan to implement a time limit feature to avoid this scenario?

[datamweb]

Due to the flexibility of the shield, this possibility can be implemented by developers in a custom way.
Currently, there is no plan for implementation by the team.

[kenjis]

The user state inactive is missing in the Session Authenticator now.

The current implementation see a inactive user as pending.
Both are restricted states. I looked into the code, there does not seem to be a need to strictly distinguish between the two.

I take back this opinon.

[pixobit]

What about multi device usage? Right now if I want to confirm the email address from a different device/browser, it would throw invalid code. The resend functionality doesn't really solve this issue, unless it's specifically mentioned for the user, otherwise it might cause confusion...

[pjsde]

Second, I think we should refactor to not rely on the session anymore. Or at least not be the only solution. At these times we would have the action information stored in user identities so we can check for the existence of them and know what needs to happen. If an email verification action exists (and the system still wants verification) ensure that step is shown first.

I agree with @lonnieezell to not rely on the session anymore

[kenjis]

I sent a PR: #391