How to restrict account changes when authenticating with Google?

SSO
1

We’re setting up Discourse for internal company use. All employees have a Google mail account with the same domain. I’ve configured our server to use Google oAuth and it is working but there is a slight problem …

What I want to do is ensure that when users sign up for Discourse with their company Google account, they are not allowed to change their username or full name. I’ve set “username change period” to 0, turned off “email editable” and selected “full name required”.

However, the user can still change both fields. Is it possible to stop that or is that just not supported in the current version?

Regards

Philip

2

Users who are “staff” are always allowed to change their username - are you sure the user you are testing with is not a “moderator” or “admin”?

Although it doesn’t technically prevent (in a secure way) the user from changing their username / real name you could add the following to both a CSS and “mobile CSS” customisation:

.user-preferences {
 .pref-username,
 .pref-name {
   display:none;
 }
}

This would just hide the controls for viewing and editing username and real name.

3 Likes
3

Hi Dean

This was at the point of registering a new account, so they shouldn’t have any status.

So it is the registration window where the changes are being made and that I want to prevent.

Regards

Philip

4

Well could also use CSS there in whilst registering the account.

5

I’ve looked at how the “Create New Account” pop-up works and I’m struggling to see how I can apply CSS in a way that would only filter out the Username and Name bits.

As far as I can tell, the HTML is this:

<table>
    <tr class="input">
          <td class="label"><label for="new-account-email">Email</label></td>
          <td>
          <input id="new-account-email" class="ember-view ember-text-field" autofocus="" disabled="" name="email" type="email">
          &nbsp;<div id="ember934" class="ember-view tip good"><i class="fa fa-check"></i> Your email has been authenticated by Google</div>
          </td>
    </tr>
    <tr class="instructions">
      <td></td>
      <td><label>Never shown to the public</label></td>
    </tr>

      <tr class="input">
            <td class="label"><label for="new-account-username">Username</label></td>
            <td>
            <input id="new-account-username" class="ember-view ember-text-field" maxlength="20" name="username" type="text">
            &nbsp;<div id="username-validation" class="ember-view tip good"><i class="fa fa-check"></i> Your username is available</div>
            </td>
      </tr>
      <tr class="instructions">
        <td></td>
        <td><label>Unique, no spaces, short</label></td>
      </tr>

      <tr class="input">
        <td style="width:80px" class="label">
          <label for="new-account-name">Name</label>
        </td>
        <td style="width:496px">
          <input id="new-account-name" class="ember-view ember-text-field" placeholder="" type="text">&nbsp;<div id="ember943" class="ember-view tip good"></div>
        </td>
      </tr>
      <tr class="instructions">
        <td></td>
        <td><label>Your full name</label></td>
      </tr>
    <tr class="password-confirmation">
      <td><label for="new-account-password-confirmation">Password Again</label></td>
      <td>
        <input id="new-account-confirmation" class="ember-view ember-text-field" type="password">
        <input id="new-account-challenge" class="ember-view ember-text-field" type="text">
      </td>
    </tr>
</table>

So, in theory, I could do something like setting the instructions and input classes so that they don’t display, but that would also knock out the Email piece … and I do want that, because if someone tries to sign up with an email address that isn’t on the whitelist, this is where they get told.

6

There is not a perfect solution here, you could:

  • Use nth-child CSS to get the the elements you want to hide
  • Override the discourse/templates/modal/create-account.hbs template and mark the fields with “readonly”.
  • Reopen the Create Account class and change the JavaScript to more suit your needs,

None of which seem appealing to me.

I’m sure someone else has a better idea.

1 Like
7

Thanks, @DeanMarkTaylor for the suggestions.

8

I’ve come up with what might be another way to do what I want, but my knowledge of how to customize Discourse is making it difficult for me.

Looking at the “Create New Account” page in more detail, I can see that the input fields have specific names, so it occurs to me that an acceptable solution would be to disable them, just like the email field is disabled, so the user can see the values but can’t alter them.

You can’t do this in CSS, so I’ve tried to come up with a way to do this in JavaScript through a customization, viz:

<!DOCTYPE html>
<script>
    document.getElementById('input#new-account-name').setAttribute('disabled');
</script>

I’m not sure what the different customization options (Header, Top, Footer, /head, /body, embedded CSS) relate to. I’ve tried Header and Top, but the customization isn’t appearing in the source of the page.

Is my approach feasible? If it is, what do I need to do in order to inject that script? I can’t find any documentation on meta about this for newbies :slight_smile:

Thanks.

1 Like
9

Don’t set fields to disabled this may prevent then from being sent to the server. Setting them to readonly should have the desired effect.

3 Likes
10

@Philip_Colmer (or anyone else out there) - Thank you for fielding this question. Were you ever able to get the input fields in the “Create New Account” page to present the user with readonly values?

If so, please provide instructions to accomplish this. I’ve looked at the discourse/templates/modal/create-account.hbs template too but admittedly to not know how or where to modify the related javascript.

We have also configured our Discourse server to use Google oAuth - and would like the “Create New Account” page to present to the user with readonly values.

Any info or leads you can provide would be much appreciated.