Hello,
I’ve been experiencing a strange and inconsistent behavior over the past couple weeks, and today I was finally able to reproduce it regularly. Basically, accounts that already have confirmed their emails are being redirected to the “confirm email” page when they log in.
The setup:
My basic authentication setup involves a “signup/login” popup that is present on the header. On the index page, the user clicks the button to show that popup, and then on first signing in, a confirmation email is sent to their email. Clicking that confirmation email will set the built-in “email is confirmed” field to “yes”, which will enable full access to their account. This seems to work fine.
However, in the case that a user logs out before confirming their email, we need to be able to prompt them to confirm it again. When a user logs in with their username and password, the workflow looks like this:
- Sign the user in
- Clear any error messages by setting a custom state to nothing
- Close the login/signup popup
- If the user’s built-in “email confirmed” field is “no”, redirect the user to the “confirm_email” page.
The behavior I was seeing is that users who had already authenticated their email were being sent via that redirect.
Debugging
However, today I implemented an additional workflow to the “confirm_email” page. This workflow will run on page load, but only if the user’s “email confirmed” field is “yes”. This workflow will then redirect the user back to the index page.
What I discovered is that when a user first logs in, they are directed to the “confirm_email” page, which then immediately redirects them back to the index. In addition, if they attempt to load other pages that also require that their “email confirmed” field be “yes”, they have no issues.
As an additional test, I added a temporary text field with the dynamic data set to the current user’s “email confirmed”, and disabled steps 3 and 4 of the login workflow so that I could view the test. While not logged in, this field reported as “no”, as expected. However, during login, I noticed that the field didn’t change to “yes” until slightly after the loading bar at the top of the page had finished.
Conclusion
It is hard to debug this issue as bubble users do not have access to several internal fields in the data tab in bubble, including “email is confirmed”. However, given that the tests are showing the true value of the “email confirmed” field to be “yes”, my guess is that the “login/signup” action is returning in the workflow before the “email confirmed” field has been set. As a result, the workflow continues and obtains the old value of “no” (obtained from a non-signed-in user).