These changes fix compatibility issues with common SQL databases including MySQL, MariaDB and Postgres.
* Fixes#147 - datetime now ANSI SQL timestamp
* Fixes#160 - AccessToken and RefreshToken type change from varchar to text
* Adds Docker Compose files to make it easier to test database integration.
TODO:
* Update documentation with configuration examples and latest compatibility info
* Create DB URI parser (currently only object config works)
* Database table/collection name prefix (will default to `next-auth_`)
* MongoDB support
MongoDB has some issues which mean it will require additional work and refactoring to support (while preserving SQL DB support, which is important).
It's going to take some thinking about to get right; MongoDB support might have to be dropped from 2.0 (and follow in a subsequent release) but I'm going to review options and consider the impact before making a call.
* Run `npm run lint` to find (and where possible, fix) linting issues.
* Includes some minor refactoring, including directory structure for adapters and models, so that code for an adapter and the models for it sit together.
Background:
I've added elint to try and ensure a consistent style and to uncover hidden bugs.
I don't actually care much about what the rules are, it's just helpful to have a baseline.
If it's hard to get code to be compliant, I would rather we just disable a rule in that block of code until we can figure it out and am totally fine with that.
I'd much prefer that than the chore of maintaining a custom set of rules, which is why I just picked Standard JS.
Unfortunately, there is quite a lot that doesn't match the Standard JS format at this point, so this is going to be a big PR.
The file size has gone down in quite a few places, which is nice. I think it may have uncovered potential bugs.
I've run through the flow and everything seems to work as before, though it took some debugging after refactoring.
I have not yet added eslint to a commit hook and am in two minds about that.
This is an open source project and I'd like to make it easy to maintain, but also to have as low a barrier to entry as possible for contributors.
I'm happy to go with encouraging folks to run the linter and try to fix errors they find and to take on the work of wrangling any issues myself.
* Redesigned from the ground up for serverless!
* Doesn't require PassportJS or Express!
* Much simpler configuration!
* Interface exposed via single API endpoint.
* Supports both oAuth 1.x and 2.x services.
* Initial commit includes support for signing in with Twitter, Google and GitHub.
Code is functional, but not useable as adapter support (saving user information) is still in progress.
Still to come:
* Support for Facebook, email, and credential authentication flows.
* Adapter support - will provide out of the box support for MongoDB, Elasticsearch and SQL with support for writing custom adapters in a similar style to version 1.x.
* Automated User Acceptance Tests for all auth flows.
* Example usage . In a change from version 1.x a demo will exist in a seperate repository to make it easier to get started.
* All dependancies updated, including the example to include latest release of Next.js and React.
* Includes fix for Keycloak strategy support and improved oAuth strategy compatibility.
* Includes enhancement for exposing additional parameters when calling getProfile().
* `sessionResave` now defaults to `true`, which ensures sessions always rotate properly.
This can be disabled for special use cases - it does not work well with some Express Session Stores, but for most people it should be fine and should rotate sessions correctly. If set to `false` user sessions are likely to expire prematurely. It is strongly recommended you do not change this from the default setting.
As a side effect, this will case all sessions - including anonymous sessions created when users have connected but not logged in yet - to be saved as a session in the store. This is because the current Cross Site Request Forgery option associates a token with a session in the browser.
If you want to avoid creating anonymous sessions, set `csrf` to `false` to disable CSRF protection; sessions will then only be created when a user signs in. A future update should include the option to implement CSRF using the Double Submit Cookie method so it can be enabled without causing this side effect.
* Added Babel Pollyfill to the next-auth client and rollup config.
* Client longer relies on ES6 features and so works in Internet Explorer (support for which had been dropped was was conflicting with newerver version of webpack when building isomorphic libraries).
* Example client now has slightly better example of how to handle the callback screen for browsers that don’t have JavaScript enabled.
* Migrated to rollup from webpack, as webpack no longer generates working isomorphic code in latest versions.
* The webpack generated client was also causing an error in Internet Explorer 11 (Microsoft Edge was and still is working fine).
* There are _still_ breaking issues in Internet Explorer 11 with the example project (cause TBD), but it no longer crashes the app, so fallback of server side rendering still works.
* Hotifx for release 1.8.3 which was a broken release (!)
* This release includes a downgrade from webpack 4.7 to webpack 3.11 (the latest release of 3.x)
* Example upgraded to latest versions of Next.js 6.0 and React/React DOM 16.3
The downgrade of webpack is due to breaking changes in webpack. Webpack 4.7 builds do not work as universal builds (that can run in web, webworker and node.js).
There is no fix or apparent workaround for this in webpack presently, but a fix has been suggested in an issue linked to in this thread: https://github.com/webpack/webpack/issues/6525
* Resolves#18 by providing an easy way to define a custom credentials based sign in end point and use it with NextAuth.
The NextAuth client explicitly supports this option and an new example in example/pages/credentials.js shows how to use it (it’s super easy to use and and you can pass any fields you like to it).
Note that this does not explicitly allow a localStrategy to be defined but provides the same ability to define a custom auth hook - allowing custom localStrategies would probably be a footgun and likely generate support requests (as it’s more complicated to implement) so I’m inclined to keep it simple for everyone.
* Resolves#20 by passing the req to email sign in method (useful for things like language and hostname detection).
* If you do not pass a sendSignInEmail() or signIn() functions (or set them to null) then the routes for these will not be created, so that they are easy to disable.
