Modular - We have you covered with Facebook and Twitter
OAuth logins, basic login/password support, and modules
coming soon for beta invitation support and more.

Easily Configurable - everyauth was built with powerful
configuration needs in mind. Configure an authorization strategy
in a straightforward, easy-to-read & easy-to-write approach,
with as much granularity as you want over the steps and
logic of your authorization strategy.

Idiomatic - The syntax for configuring and extending your authorization strategies are
idiomatic and chainable.

Important - Some OAuth Providers do not allow callbacks to localhost, so you will need to create a localhost
alias called local.host. Make sure you set up your /etc/hosts so that 127.0.0.1 is also
associated with 'local.host'. So inside your /etc/hosts file, one of the lines will look like:

everyauth assumes that you store your users with an id property. If not --
e.g, if you adopt the convention user.uid over user.id -- then just make
sure to configure the everyauth.everymodule.userPkey parameter:

If you already have an express helper named user, then you can configure
everyauth to use a different helper name to access the user object that
everyauth manages. To do so, leverage the userAlias option for
everyauth.helpExpress:

everyauth.helpExpress(app,{ userAlias:'__user__'});

Then, you could access the user object in your view with the helper __user__
instead of the default helper user. So you can compare with the default use
of helpers given previously, the alternative leveraging userAlias would look like:

If you integrate everyauth with connect, then everyauth automatically
sets up a logoutPath at GET/logout for your app. It also
sets a default handler for your logout route that clears your session
of auth information and redirects them to '/'.

You may want your own callback that decides where to send a user after login or registration. One way of doing this is with the respondToLoginSucceed and respondToRegistrationSucceed methods. This assumes that you have set a .redirectTo property on your req.session object:

everyauth.password

.respondToLoginSucceed(function(res, user, data){

if(user){

this.redirect(res, data.session.redirectTo)

}

})

.respondToRegistrationSucceed(function(res, user, data){

this.redirect(res, data.session.redirectTo)

})

If you are using express and want your redirects to be subject to express
redirect mapping, you can
overwrite redirect method employed by everyauth.

everyauth.everymodule

.performRedirect(function(res, location){

res.redirect(location,303);

});

A newly defined method will be used by everyauth to perform all redirects.

Facebook provides many different
permissions
for which your app can ask your user. This is bundled up in the scope query
paremter sent with the oauth request to Facebook. While your app may require
several different permissions from Facebook, Facebook recommends that you only
ask for these permissions incrementally, as you need them. For example, you might
want to only ask for the "email" scope upon registration. At the same time, for
another user, you may want to ask for "user_status" permissions because they
have progressed further along in your application.

everyauth enables you to specify the "scope" dynamically with a second
variation of the configurable scope. In addition to the first variation
that looks like:

everyauth.facebook

.scope('email,user_status');

you can have greater dynamic control over "scope" via the second variation of scope:

If you are programming for mobile, you can bring up the facebook mobile OAuth
dialog instead of the traditional desktop browser-based one by just adding
mobile(true) to your configuration as seen here:

Important - Some developers forget to do the following, and it causes them to have issues with everyauth.
Please make sure to do the following: When you set up your app at http://dev.twitter.com/, make sure that your callback url is set up to
include that path '/auth/twitter/callback/'. In general, when dealing with OAuth or OAuth2 modules
provided by everyauth, the default callback path is always set up to follow the pattern
'/auth/#{moduleName}/callback', so just ensure that you configure your OAuth settings accordingly with
the OAuth provider -- in this case, the "Edit Application Settings" section for your app at http://dev.twitter.com.

Alternatively, you can specify the callback url at the application level by configuring callbackPath (which
has a default configuration of "/auth/twitter/callback"):

So if your hostname is example.com, then this configuration will over-ride the dev.twitter.com callback url configuration.
Instead, Twitter will redirect back to example.com/custom/twitter/callback/path in the example just given above.

You can also configure more parameters (most are set to defaults) via
the same chainable API:

everyauth.twitter

.entryPath('/auth/twitter')

.callbackPath('/auth/twitter/callback');

If you want to see what the current value of a
configured parameter is, you can do so via:

everyauth.twitter.callbackPath();// '/auth/twitter/callback'

everyauth.twitter.entryPath();// '/auth/twitter'

To see all parameters that are configurable, the following will return an
object whose parameter name keys map to description values:

By default, everyauth uses the field and user key name login during the
registration and login process.

Sometimes, you want to use email or phone instead of login. Moreover,
you also want to validate email and phone fields upon registration.

everyauth provides an easy way to do this:

everyauth.password.loginWith('email');

// OR

everyauth.password.loginWith('phone');

With simple login configuration like this, you get email (or phone) validation
in addition to renaming of the form field and user key corresponding to what
otherwise would typically be referred to as 'login'.

If you are using express, you are able to pass variables from your app
context to your view context via local variables. everyauth provides
several convenience local vars for your views, but sometimes you will want
to augment this set of local vars with additional locals.

So everyauth also provides a mechanism for you to do so via the following
configurables:

everyauth.password.loginLocals(...);

everyauth.password.registerLocals(...);

loginLocals and registerLocals configuration have symmetrical APIs, so I
will only cover loginLocals here to illustrate how to use both.

You can configure this parameter in one of 3 ways. Why 3? Because there are 3 types of ways that you can retrieve your locals.

Static local vars that never change values:

```javascript
everyauth.password.loginLocals({
title: 'Login'
});
```

Dynamic synchronous local vars that depend on the incoming request, but whose values are retrieved synchronously

By default, everyauth is agnostic about how you decide to store your users and
therefore passwords. However, one should always use password hashing and
salting for security.

Here's an example of how to incorporate password hashing into everyauth using
bcrypt hashing. The idea is to store a salt and hash value inside your user object
instead of the password. The hash value is generated from the password (sent with a
registration or login request) and unique salt per user, using the bcrypt algorithm.

You will first need to register an app to get the consumer key and secret.
During registration of your new app, enter a "Default callback URL" of "http://:/auth/tumblr/callback".
Once you register your app, copy down your "OAuth Consumer Key" and "Secret Key" and proceed below.

You will first need to request an API key to get the consumer key and secret. Note that this consumer key and secret will only be valid for the sandbox rather than the production OAuth host. By default the Evernote module will use the production host, so you'll need to override this using the chainable API if you're using the sandbox.

You will first need to login to OpenStreetMap. Then register you application on your OpenStreetMap user page via the View my OAuth details link on the bottom of the page to get the consumer key and secret. The registered application does not need any permission listed there to login via OAuth.

var everyauth =require('osm')

, connect =require('connect');

everyauth.osm

.consumerKey('YOUR CONSUMER KEY HERE')

.consumerSecret('YOUR CONSUMER SECRET HERE')

.findOrCreateUser(function(sess, accessToken, accessSecret, user){

// find or create user logic goes here

//

// e.g.,

// return usersByOSMId[user.id] || (usersByOSMId[user.id] = user);

})

.redirectPath('/');

varroutes=function(app){

// Define your routes here

};

connect(

connect.bodyParser()

, connect.cookieParser()

, connect.session({secret:'whodunnit'})

, everyauth.middleware()

, connect.router(routes);

).listen(3000);

You can also configure more parameters (most are set to defaults) via
the same chainable API:

everyauth.osm

.oauthHost('http://api06.dev.openstreetmap.org')

.entryPath('/auth/osm')

.callbackPath('/auth/osm/callback');

If you want to see what the current value of a
configured parameter is, you can do so via:

everyauth.osm.oauthHost();// 'http://api.openstreetmap.org'

everyauth.osm.callbackPath();// '/auth/osm/callback'

everyauth.osm.entryPath();// '/auth/osm'

To see all parameters that are configurable, the following will return an
object whose parameter name keys map to description values:

You will first need to register an app to get the client id and secret.
During registration of your new app, enter a "Default callback URL" of "http://:/auth/soundcloud/callback".
Once you register your app, copy down your "Client ID" and "Client Secret" and proceed below.

var everyauth =require('everyauth')

, connect =require('connect');

everyauth.soundcloud

.appId('YOUR CLIENT ID HERE')

.appSecret('YOUR CLIENT SECRET HERE')

.handleAuthCallbackError(function(req, res){

//TODO - Update this documentation

// This configurable route handler defines how you want to respond to

// a response from SoundCloud that something went wrong during the oauth2 process.

You will need to create a Windows Azure ACS namespace. The only caveat when creating the namespace is setting the "Return URL". You will probably create one Relying Party for each environment (dev, qa, prod) and each of them will have a different "Return URL". For instance, dev will be http://localhost:port/auth/azureacs/callback and prod could be https://myapp.com/auth/azureacs/callback (notice the /auth/azureacs/callback, that's where the module will listen the POST with the token from ACS)

Every module comes with a set of parameters that you can configure
directly. To see a list of those parameters on a per module basis,
with descriptions about what they do, enter the following into the
node REPL (to access the REPL, just type node at the command line)

> var ea = require('everyauth');
> ea.facebook.configurable();

For example, you will see that one of the configuration parameters is
moduleTimeout, which is described to be how long to wait per step before timing out and invoking any timeout callbacks

Every configuration parameter corresponds to a method of the same name
on the auth module under consideration (i.e., in this case
ea.facebook). To create or over-write that parameter, just
call that method with the new value as the argument:

ea.facebook

.moduleTimeout(4000);// Wait 4 seconds before timing out any step

// involved in the facebook auth process

Configuration parameters can be scalars. But they can be anything. For
example, they can also be functions, too. The facebook module has a
configurable step named findOrCreateUser that is described as
"STEP FN [findOrCreateUser] function encapsulating the logic for the step
fetchOAuthUser.". What this means is that this configures the
function (i.e., "FN") that encapsulates the logic of this step.

ea.facebook

.findOrCreateUser(function(session, accessToken, extra, oauthUser){

// find or create user logic goes here

});

How do we know what arguments the function takes?
We elaborate more about step function configuration in our
Introspection section below.

Everyauth also supports a special method configure for coffee-script
aficionados. Coffee and chainable APIs often don't mix well. As an alternative,
you can configure an everyauth module using an Object passed to configure:

everyauth provides convenient methods and getters for finding out
about any module.

Show all configurable parameters with their descriptions:

everyauth.facebook.configurable();

Show the value of a single configurable parameter:

// Get the value of the configurable callbackPath parameter

everyauth.facebook.callbackPath();// => '/auth/facebook/callback'

Show the declared routes (pretty printed):

everyauth.facebook.routes;

Show the steps initiated by a given route:

everyauth.facebook.route.get.entryPath.steps;

everyauth.facebook.route.get.callbackPath.steps;

Sometimes you need to set up additional steps for a given auth
module, by defining that step in your app. For example, the
set of steps triggered when someone requests the facebook
module's callbackPath contains a step that you must define
in your app. To see what that step is, you can introspect
the callbackPath route with the facebook module.

everyauth.facebook.route.get.callbackPath.steps.incomplete;

// => [ { name: 'findOrCreateUser',

// error: 'is missing: its function' } ]

This tells you that you must define the function that defines the
logic for the findOrCreateUser step. To see what the function
signature looks like for this step:

Each everyauth auth strategy module is composed of steps. As each step begins and ends, everyauth will print out to the console the beginning and end of each step. So by turning on the debug flag, you get insight into what step everyauth is executing at any time.

For example, here is some example debugging information output to the console
during a Facebook Connect authorization:

By default, every module has 10 seconds to complete each step. If a step takes longer than 10 seconds to complete, then everyauth will pass a timeout error to your configured error handler (see section "Configure Error Handling" above).

If you would like to increase or decrease the timeout period across all modules, you can do so via:

everyauth.everymodule.moduleTimeout(2000);// Wait 2 seconds per step instead before timing out

You can eliminate the timeout altogether by configuring your timeouts to -1:

everyauth.everymodule.moduleTimeout(-1);

You can also configure the timeout period on a per module basis. For example, the following will result in the facebook module having 3 seconds to complete each step before timing out; all other modules will have the default 10 seconds per step before timing out.

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
THE SOFTWARE.