Access Denied while editing old email address confirmation

ux
1

Hi there,

I think something broke on my Discourse instance while editing text entries on the Personalization panel. Any hint on how to procced would be really appreciated, since I’m not getting really any information about what’s going here.

This what I get each time I press EDIT on this entry:

48%20AM
Screen Shot 2019-10-24 at 2.46.48 AM.png757×275 18.7 KB

Here’s what it look on the logs:

|message|Uncaught [object Object]|
|---|---|
|url|https://******/assets/ember_jquery-82558c4b4178a5371667ae9e87d3a56c737126be9d1394ca3dfde2d3833187f|
|line|1|
|column|262400|
|window_location|https://******/admin/customize/site_texts?q=email_prefix|

Thanks in advance!

1 Like
2

I can repro this here on Meta with all three of the user_notifications.confirm_old_email templates. We’ll definitely take a look. Thanks for reporting this!

4 Likes
3

Reminder that these confirm old email templates are not allowed to be changed for security reasons, in the case of staff accounts where both new and old email must be confirmed on email change.

For normal users only the new email has to be confirmed but that is not the case for staff.

3 Likes
4

Yes I was looking at this issue and it’s def expected:

  def self.restricted_keys
    ['user_notifications.confirm_old_email.title',
     'user_notifications.confirm_old_email.subject_template',
     'user_notifications.confirm_old_email.text_body_template']
  end

Also the error message seems OK as it’s showing a 403. Could probably be more explicit, but nothing very broken here.

3 Likes
5

It looks like there was supposed to have been a more explicit message added at one point:

3 Likes
6

Thank you all for the follow up.

I’m cleaning email subjects from [email_prefix] since the sender name is the same as site title and don’t want to have that duplicated.

Would be able to edit that entry in some way? It doesn’t seem to be a security issue for me.

1 Like
7

If edited, it potentially turns into a phishing mail so editing that one is not allowed.

1 Like
8

You may already be aware, but you can edit the email prefix to be something other than the site title via the email prefix site setting.

2 Likes
9

Ok, thanks for the clarification. I assume your are right about that @codinghorror

Yep, I’ve seen that option but the brackets [—] are still there, even if there’s no need to add anything.

We can extract to possible outcomes from this:

  1. Add a better explanation to error, or even better prevent that error.
  2. Move [—] inside ‘email_prefix’ so you can manipulate it globally from settings

Thanks