next-auth: Users unable to login on production build

Since synchronising the schema is dangerous and removing that if statement is not possible without forking the library I tried simply writing the model/schema from scratch instead of extending the provided model. This works for me and it is the only workaround I could find.

Workaround

If you have a custom model, for example you add a role column to the users table

import Adapters from 'next-auth/adapters';

// Extend the built-in models using class inheritance
export default class User extends Adapters.TypeORM.Models.User.model {
  // You can extend the options in a model but you should not remove the base
  // properties or change the order of the built-in options on the constructor
  constructor(name, email, image, emailVerified) {
    super(name, email, image, emailVerified);
  }
}

export const UserSchema = {
  name: 'User',
  target: User,
  columns: {
    ...Adapters.TypeORM.Models.User.schema.columns,
    role: {
      type: 'varchar',
      nullable: true,
    },
  },
};

instead do it without extending the class

export default class User {
  constructor(name, email, image, emailVerified) {
    if (name) {
      this.name = name;
    }
    if (email) {
      this.email = email;
    }
    if (image) {
      this.image = image;
    }
    if (emailVerified) {
      const currentDate = new Date();
      this.emailVerified = currentDate;
    }
  }
}

export const UserSchema = {
  name: 'User',
  target: User,
  columns: {
    id: {
      primary: true,
      type: 'int',
      generated: true,
    },
    name: {
      type: 'varchar',
      nullable: true,
    },
    email: {
      type: 'varchar',
      unique: true,
      nullable: true,
    },
    emailVerified: {
      type: 'timestamp',
      nullable: true,
    },
    image: {
      type: 'varchar',
      nullable: true,
    },
    createdAt: {
      type: 'timestamp',
      createDate: true,
    },
    updatedAt: {
      type: 'timestamp',
      updateDate: true,
    },
    role: {
      type: 'varchar',
      nullable: true,
    },
  },
};

this “solves” the problem.

We have the exact same issue, in dev mode it works perfectly, but on production mode it duplicates the table and you get users_users, etc.

Hi ian,

Indeed i tested by connecting the production build to the same DB i am using in the dev environment and I was still facing this issue. As a workaround I created two new views account_accounts and user_users in the db. For some reason in the production build, next-auth is trying to query account_accounts and user_users instead of accounts and users when using custom models.

I can confirm I have the same issue and @fedekau “solution” works

I am having an issue with next auth in production whenever I clink in sign in it shows /api/auth/signin?=true and reloads the page never signs in

Some of the replies ere are really helpful, especially this one from @fedekau which I think is a good one that should be followed up:

Looking very quickly to the code, why is https://github.com/nextauthjs/next-auth/blob/main/src/adapters/typeorm/index.js#L72 needed on non production envs only? I think it might be related to the issue thinking

The comments above from @deep-c and the issues @archywillhe has linked to are also helpful and interesting.

As this discussion seems to have become quite broad (and is about more than one specific thing; with no single action that seems obvious arising from this) I’m going to mark this issue as closed now and suggest that anyone with issues related to migration raise them in the Discussions area that we have now.

Please do also raise a feature request if you can identify ways we could make changes (in code and/or documentation) to help folks avoid doing whatever they are doing that is triggering problems with table names.

Likewise if we think there is a race condition or behaviour that is explicitly incorrect please do raise a bug about that behaviour.

A critical thing we need to be able to understand why these are happening is code to replicate any problems - in particular we need to understand how folks are building and compiling their apps to see where the problem is.

To confirm, I do not see these issues myself with either TypeORM or Prisma adapters on production sites, including in cases with custom models.

Specific challenges I think we have include that the guidance we have on how to use custom models is sparse, it may need to be reviewed and I suspect there are some issues specific to folks using TypeScript run into too.

There are also issues with different version of TypeORM from time to time, so understand what versions of libraries people are suing is also helpful when it comes to replicating problems.

We do have working schema creation tests for a range of databases with the default adapter (Postgres, MySQL, MSSQL, MongoDB…) and they test table/collection creation/column types/indexes/etc. IIRC they do not current include examples of custom models but those should be easy to extend.

We may wish to do that and then go back and see if we can improve some of the examples/tutorials for the default adapter.

Feel free to create feature request to extend those example and link back to this issue.

Im having the same problem as @jmaister above trying to create a migration via typeorm. All models etc are in typescript and I am invoking the following

"typeorm": "cross-env TS_NODE_PROJECT=tsconfig.typeorm.json TS_NODE_TRANSPILE_ONLY=true ts-node -r tsconfig-paths/register ./node_modules/typeorm/cli.js"

npm run typeorm migration:generate -- -n Initial

Fixed by moving to Passport.js It took 2 hours to remove next-auth and implement it with Passport.js, however I lost the email confirmations. But users can create their accounts and login.

Im having the same problem as @jmaister above trying to create a migration via typeorm. All models etc are in typescript and I am invoking the following

"typeorm": "cross-env TS_NODE_PROJECT=tsconfig.typeorm.json TS_NODE_TRANSPILE_ONLY=true ts-node -r tsconfig-paths/register ./node_modules/typeorm/cli.js"

npm run typeorm migration:generate -- -n Initial

I get the following error:

Error during migration generation:
TypeError: Cannot read property 'TypeORM' of undefined
    at Object.<anonymous> (/usr/src/app/src/models/User.ts:3:45)
    at Module._compile (internal/modules/cjs/loader.js:1063:30)
    at Module.m._compile (/usr/src/app/node_modules/ts-node/src/index.ts:1056:23)
    at Module._extensions..js (internal/modules/cjs/loader.js:1092:10)
    at Object.require.extensions.<computed> [as .ts] (/usr/src/app/node_modules/ts-node/src/index.ts:1059:12)
    at Module.load (internal/modules/cjs/loader.js:928:32)
    at Function.Module._load (internal/modules/cjs/loader.js:769:14)
    at Module.require (internal/modules/cjs/loader.js:952:19)
    at require (internal/modules/cjs/helpers.js:88:18)
    at Object.<anonymous> **(/usr/src/app/src/models/index.ts:1:1)**

tsconfig file used

{
    "compilerOptions": {
        "lib": ["es5", "es6"],
        "target": "es6",
        "module": "commonjs",
        "moduleResolution": "node",
        "emitDecoratorMetadata": true,
        "experimentalDecorators": true,
        "sourceMap": true,
        "baseUrl": "src",
        "paths": {
            "@/*": ["*"]
        }
    },
    "exclude": ["node_modules"]
}

custom user model:

import Adapters, { TypeORMUserModel } from 'next-auth/adapters';

export default class User extends (Adapters.TypeORM.Models.User.model as typeof TypeORMUserModel) {
    constructor(name?: string, email?: string, image?: string, emailVerified?: Date) {
        super(name, email, image, emailVerified);
    }
}

export const UserSchema = {
    name: 'User',
    target: User,
    columns: {
        ...Adapters.TypeORM.Models.User.schema.columns,
        dob: {
            type: Date,
            nullable: true,
        },
    },
};

I can’t extend the User model to make it available. It seems to work for others in this issue.

jordi@jordi-ssd-t5:~/workspace/furgos$ yarn typeorm migration:show
yarn run v1.22.5
$ TYPEORM=true yarn local ./node_modules/typeorm/cli.js --config ormconfig.ts migration:show
$ DOTENV_CONFIG_PATH=./.env ts-node -P ./tsconfig.typeorm.json -r dotenv/config ./node_modules/typeorm/cli.js --config ormconfig.ts migration:show
Error during migration show:
TypeError: Cannot read property 'TypeORM' of undefined
    at Object.<anonymous> (/home/jordi/workspace/furgos/src/entity/User.ts:3:25)

@archywillhe Another way around this for now if your having problems is to manually rename it:

class User extends Adapters.TypeORM.Models.User.model {
  // You can extend the options in a model but you should not remove the base
  // properties or change the order of the built-in options on the constructor
  constructor(name, email, image, emailVerified) {
    super(name, email, image, emailVerified)
  }
}

Object.defineProperty(User, "name", { value: "User" })

got into this too; I think @fedekau’s hot fix work for many cases! But in my case I have another couple of api calls using the TypeORM adaptor to perform CURD operations with custom models, and I’m inconsistently getting some weird EntityMetadataNotFoundError (only in serverless setting; works perfectly locally & on heroku! ) : - /

could be related to this:

https://github.com/typeorm/typeorm/issues/1327

maybe something to do with the constraint in a serverless setting and some of the stuff in typeORM weren’t implemented with serverless in mind?

Hmm or could also be due to some optimsiation done in Vercel for the functional calls I guess. just opened a discussion here: https://github.com/vercel/vercel/discussions/5299 Really hoping to get this fixed before we launch our app : 0