[solved?]Potential bug in AccountsTemplates

core
1

I haven’t had much time to comb through the useraccounts core code yet, but in the meantime I wanted to mention the issue I ran into here in case it turns out I’m just doing something dumb. I’m using the useraccounts-configuration.js file a la the “Todos” example, and have the following code in it:

//...
AccountsTemplates.addFields([
  {
    _id: "username",
    type: "text",
    displayName: "username",
    required: true,
    trim: true,
    re: /^((?!(\bsignin\b|\bjoin\b|\badmin\b|\babout\b|\bfeedback\b|\btest\b)).)*$/,
    minLength: 3,
    errStr: 'Reserved username',
  },
  //...

The regex is meant to act as a blacklist for certain reserved names, and it works for the most part, restricting anything listed inside it (like “admin”, “about”, “join”, etc). However, I’ve found that it’s very easy to circumvent the check by first entering a valid username and then the restricted one. I haven’t done an exhaustive test, but the behavior feels intermittent (happens around 50% of the time on my local build and is currently an issue on the live website), and generally requires you to hit the “enter” key first (clicking on the “register” button seems to trigger the regex test).

I made a quick video of it happening on my local build, after I added the word “test” to the blacklist. It’s entirely possible that my regex is bad, but this seems more like an issue of when the UserAccounts core runs its validation checks. I’ll post the video once it’s finished uploading.

Thanks, all!

2

Here’s the issue in action:

3

Quick update: I went through most of the useraccounts:core code to find out when and how the signup fields are getting validated, and ended up getting more confused than less. Based on the code hosted on Github, it seems that the Field.prototype.validate function is run on the client after submitting the at-pwd-form, and then if that passes, again inside the “ATCreateUserServer” Meteor method. This process matches the at_pwd_form.js file on my own machine, but then I looked for the server.js and server_methods.js files and couldn’t find them. Hence, “ATCreateUserServer” is getting called but doesn’t look like it actually exists.

I’m not even sure if that’s the reason for the issue in question, but that’s as close as I could narrow it down to without resetting my local DB in order to put logs inside the package code. It turns out that all validation is turned off (including minLength and even required) when reproducing this error, which makes it a much more serious issue than a few reserved keywords.

If it would be helpful, here’s the full code of my useraccounts-configuration.js:

import { AccountsTemplates } from 'meteor/useraccounts:core';
import { TAPi18n } from 'meteor/tap:i18n';

AccountsTemplates.configure({
  showForgotPasswordLink: true,
  texts: {
    errors: {
      loginForbidden: TAPi18n.__('Incorrect username or password'),
      pwdMismatch: TAPi18n.__('Passwords don\'t match'),
    },
    title: {
      signIn: TAPi18n.__('Sign In'),
      signUp: TAPi18n.__('Join'),
    },
  },
  defaultTemplate: 'Auth_page',
  defaultLayout: 'App_body',
  defaultContentRegion: 'main',
  defaultLayoutRegions: {},
});

var pwd = AccountsTemplates.removeField('password');
AccountsTemplates.removeField('email');
AccountsTemplates.addFields([
  {
    _id: "username",
    type: "text",
    displayName: "username",
    required: true,
    trim: true,
    re: /^((?!(\bsignin\b|\bjoin\b|\badmin\b|\babout\b|\bfeedback\b|\btest\b)).)*$/i,
    minLength: 3,
    maxLength: 25,
    errStr: 'Reserved or invalid username',
  },
  {
    _id: 'email',
    type: 'email',
    required: true,
    displayName: "email",
    re: /.+@(.+){2,}\.(.+){2,}/,
    errStr: 'Invalid email',
  },
  pwd
]);`
4

Bump with a more concise explanation of the error in this issue, as well as a place to demo it. I wonder if there’s something simple that I’m doing wrong with AccountsTemplates.addFields, or if this is affecting anyone else who followed the useraccounts guide?

5

So, after a lot more digging I believe I found the solution. It’s PR’d, but the meteor-useraccounts repo doesn’t seem all that active. I copied the package files to my local packages/ directory and made the change manually to triage my own situation, so until it gets updated I’d recommend that anyone using this pattern in their app fix it manually as well.