An issue with the defaults for MySQL used by TypeORM Adapter has been highlighted during testing parity with the Prisma Adapter.
This change ensures *all* TIMESTAMP columns use TIMESTAMP(6) to store six digits of precision after the number of seconds.
While this is level of precision is not required everywhere it ensures all timestamps in the default models use the same configuration (instead of a mix of values) and is consisitant with the level of precision on timestamps used Postgres.
This doesn't technically do anything (except for the mongodb peer dependancy, which is invoked when a mongodb is being used) but it provides a way for us to indicate and track the last known good versions of database clients for NextAuth.js.
* Uses `require_optional` and `peerOptionalDependencies` instead of dynamic import to resolve issue some users have experience with using using compliers/bundlers (especially on starter projects) that don't handle dynamic imports well.
This should (hopefully) also make it easier to support older versions of Internet Explorer by avoiding bundlers that choke on dynamic imports unless MongoDB is included as a dependancy (even though it's not code they need to compile).
We use `require_optional` to load `ObjectID` conditionally, if NextAuth.js is using MongoDB. This is also exactly how the MongoDB driver itself loads the ObjectID from the `bson/bson-ext` module.
Should resolve#251
* The default name for the TypeORM connection is now 'nextauth' instead of 'default'.
This should help people avoid problems with connection re-use when not using serverless (including in local development), especially if they are doing things with their default connection that differ from whats expected by NextAuth.js (like not using UTF-8 for encoding or UTC timezones).
* Now uses connection manager object from the connection, to allow a custom TypeORM connection name to be specified (resolves#459).
Working implementation (with limited key length and no exp check) using node-jose from Cisco.
I want to compare it panva/jose which has more features before building it out.
Now that we are going to expose the option to disable encryption on tokens we need to enforce the algorithm is valid (e.g. not 'None' or 'RSA') to prevent vultrabilties being exploited by tampering with the token.
Custom encode/decode routines can be specified if someone needs to use another algorithm.
