Confirmation email link (after change) is broken ("Oops!") due to bad email customization

Support
1

This seems to only happen if the email is changed. Eg,

https://forum.{mySite}.com/u/{user}/preferences/email

  1. User successfully receives confirmation email
  2. User clicks link
  3. User gets err: "Oops! Page not found or private"

image

Confirmation email link template:

%{base_url}/u/authorize-email/%{email_token}

Actual confirmation email link:

https://forum.{mySite}.com/u/authorize-email/{someHash}

image

4 Likes
2

Can you repro this @tshenry?

3 Likes
4

It happened on ours too this week, just as described above.

5

You probably customized that email before we changed the link.

Please go to /admin/customize/email_templates/user_notifications.confirm_new_email and make sure that link in there looks like

%{base_url}/u/confirm-new-email/%{email_token}

instead of

%{base_url}/u/authorize-email/%{email_token}

It might be a good idea to add a migration after all. This came up multiple times already.
cc @sam

13 Likes
6

That took care of the broken link… sort of; now, it just redirects the user to the login screen.

Although it’s good this came to my attention to ensure folks can change their email, how come there’s no way for an admin to edit email from the admin panel? The only way was to impersonate >> profile >> change email? That’s what I read, anyway - is that truly the legit way to do this?

I can delete an account and impersonate but not change an email? Seems a bit counter-intuitive~

2 Likes
7

%{base_url}/u/confirm-new-email/%{email_token}

My link looks like that and it’s still sending people to an Oops error message. Are you saying it should be the other way round?

1 Like
8

For me, %{base_url}/u/confirm-new-email/%{email_token} redirects people to login page without activating the account. The other one is the “oops” page.

1 Like
9

This is weird but:
It was this:
%{base_url}/u/confirm-new-email/%{email_token}and gave an error message

I changed it to this:
%{email_token}/u/authorize-email/%{base_url} . and it still gave an error message

I changed it back to this:
%{base_url}/u/confirm-new-email/%{email_token} manually (not by resetting it)
and now it works! :woman_shrugging:

edit: oh and now it doesn’t again.

4 Likes
10

I would like to punt on this for a bit longer.

3 Likes
11

What about a backwards-compatible (deprecated) mirror link? Or a replacement script for a few versions? Could replace() the old %{} with new %{} next ver? If already migrated, nothing would happen.

But either way – my issue isn’t resolved… or, so it seems: It just shoots them to login screen without activation.

https://forum.{mySite}.com/u/confirm-new-email/{someHash}

^ Is this correct? The person insists they used incognito and showed screenshot of a login screen. Upon inspection, I can see that the old email address is still showing in admin.

12

I am not following, why not simply delete all your relevant locale customization and start from scratch?

4 Likes
14

Because like me and others – they have no idea this even happened. It’s not like the “Click to update” button had flashing lights telling us to change our email template.

I did exactly that, but:

  1. You won’t even know this is happening if you didn’t specifically discover the issue, Google the issue, find this post, and manually resolve it.
  2. This is not an intuitive process at all (on top of assuming that the user will magically know this is happening), which is out of character for Discourse.
  3. Accuracy lost and tediousness - if you mess up the template, you need a mock email to test. You won’t even know what to change it to without finding this post.

Heck, I’ve had an account here and I still had no idea about this and had to dig for a fix. Imo, it’s unacceptable for the Discourse admin experience compared to any other update (it’s the first “intentionally breaking” update I’ve experienced). I’m not asking for me since I resolved it as you said – but for others.

Who knows how long this was happening on my forum. I wonder how many new-users we lost because we had no idea x update had a breaking template change? There’s no way I’m going to be the only one.

5 Likes
15

Just wanted to follow-up on this

1 Like
16

I never customized it. It contains %{base_url}/u/confirm-new-email/%{email_token} like you advised, but in the actual email there is /authorize-email/ in the link. So I guess something goes wrong between the web admin panel and the some config file deep down in the engine room of Discourse. Running 2.5.0.beta6

Edit: even more strange: when an admin changes email address a confirmation to the old address gets it with %{base_url}/u/confirm-new-email/%{email_token} but the new address gets it with %{base_url}/u/authorize-email/%{email_token}

1 Like
17

@Willemb2 we found on our instance that the problem only occurred for users who had their interface set to a specific languge. So no matter how many times I tried to set it in the language I was using, it made no difference for those speaking French. I had to set my own interface to French and then suddenly it let me customize the French version and we haven’t had the problem since.

2 Likes
18

@gh_irina I checked this, but it also happens for users with default language (in our case: Dutch).

1 Like
19

Oh, that is annoying. I’m sorry.

20

I just hit this issue on a forum I am a member of. I managed to work around it by manually adjusting the link. For these breaking changes, why not include a catcher for the old link to alert the admin?