Two different strategies are adopted, one for when the user authenticates locally and the other through providers. When authenticating locally, the signin function in the client controller redirects to the previous state (storing and using a state name) after successful login. When authenticating through a provider, the first call to provider stores the previous URL (not state, URL) in the session. Then, when provider actually calls the authentication callback, session redirect_to path is used for redirecting user.
Emails are made unique. When user attempts to sign in through a provider in which his email is one that is already registered, user is redirected to the signin page with an error passed as a query string parameter.
The user password salt should be encoded with Base64 before being saved
to the database.
The current code adds an unecessary step of converting the result of
crypto.randomBytes() (which already returns a SlowBuffer) to a Base64
string and back again to a Buffer, and misses the final step of
converting the Buffer's bytes back to a Base64 string.
Because of this, the salt stored in the database is garbled. This is
inconvenient when manipulating the data in a terminal or text editor.
When generating the password hash, the crypto.pbkdf2Sync() method
creates a new Buffer directly from the data supplied. Due to the
incorrect encoding of the salt, entropy is lost at this step,
weakening the security of stored passwords against brute force attacks.
The executable bit is set for a lot of files where it is not necessary
to have the executable bit set. This PR removes the executable bit from
those files.
For Fb, use the Graph API. For twitter, use the 'bigger' profile image. Larger profile images (like the one provided by Google) could provide more flexibility.
