I thought we would do

    helper_method :current_user, :logged_in?, :authorized?

to make these controller methods available for use as helper methods in views. But in Restful Authentication&#39;s `lib/authenticated_system.rb`, I see:

    # Inclusion hook to make #current_user and #logged_in?
    # available as ActionView helper methods.
    def self.included(base)
      base.send :helper_method, :current_user, :logged_in?, :authorized? if base.respond_to? :helper_method
    end

Why is it done this way instead of that single line? Also, I don&#39;t see `included` being called anywhere.




What does #self.included(base) do in Ruby on Rails&#39; Restful Authentication?

What does RESTful Authentication mean and how does it work?  I can&#39;t find a good overview on Google.  My only understanding is that you pass the session key (remeberal) in the URL, but this could be horribly wrong.

RESTful Authentication

I am currently developing a REST-API which is HTTP-Basic protected for the development environment. As the real authentication is done via a token, I&#39;m still trying to figure out, how to send two authorization headers.

I have tried this one:

    curl -i http://dev.myapp.com/api/users \
      -H &quot;Authorization: Basic Ym9zY236Ym9zY28=&quot; \
      -H &quot;Authorization: Bearer mytoken123&quot;

I could for example disable the HTTP-Authentication for my IP but as I usually work in different environments with dynamic IPs, this is not a good solution. So am I missing something?

Basic HTTP and Bearer Token Authentication

I&#39;m building a RESTful API with Django and [django-rest-framework][1].

As authentication mechanism we have chosen &quot;Token Authentication&quot; and I have already implemented it following Django-REST-Framework&#39;s documentation, the question is, should the application renew / change the Token periodically and if yes how? Should it be the mobile app that requires the token to be renewed or the web-app should do it autonomously?

What is the best practice?

Anybody here experienced with Django REST Framework and could suggest a technical solution?

(the last question has lower priority)


  [1]: http://www.django-rest-framework.org/

Token Authentication for RESTful API: should the token be periodically changed?

For the purpose of securing REST API using JWT, according to some materials (like this [guide](https://auth0.com/blog/2016/01/04/secure-your-react-and-redux-app-with-jwt-authentication/) and this [question](https://stackoverflow.com/questions/27067251/where-to-store-jwt-in-browser-how-to-protect-against-csrf)), the JWT can be stored in either **localStorage** or **Cookies**. Based on my understanding:

 - **localStorage** is subjected to XSS and generally it&#39;s not recommended to store any sensitive information in it.
 - With **Cookies** we can apply the flag &quot;httpOnly&quot; which mitigates the risk of XSS. However if we are to read the JWT from Cookies on backend, we then are subjected to CSRF.

So based on the above premise - it will be best if we store JWT in Cookies. On every request to server, the JWT will be read from Cookies and added in the Authorization header using Bearer scheme. The server can then verify the JWT in the request header (as opposed to reading it from the cookies).

Is my understanding correct? If so, does the above approach have any security concern? Or actually we can just get away with using localStorage in the first place?

Should JWT be stored in localStorage or cookie?

A similar question is posted here: https://stackoverflow.com/questions/1959947/whats-an-appropriate-http-status-code-to-return-by-a-rest-api-service-for-a-val

The answer in the thread above states that &quot;For instance if the URI is supposed to have an ISO-8601 date and you find that it&#39;s in the wrong format or refers to February 31st, then you would return an HTTP 400. Ditto if you expect well-formed XML in an entity body and it fails to parse.&quot;

However, what happens if the user submitted correctly formatted data? By this I mean, the user submitted a plain alphabetical string / text for the username and password (which is perfectly valid for my application). The only issue is that the password did not match with the username. In this case, 400 will be incorrect because it is perfectly valid syntax and well-formed. 

A 401 would be incorrect (as suggested here: https://stackoverflow.com/questions/26093875/wich-http-status-code-to-say-username-or-password-were-incorrect) because the user is not trying to access any page, he is simply trying to login and entered data which does not match.

If you look back at the first post I linked to, the second answer states that 422 is the correct response (and it looks correct to me), however, I am using Django Rest Framework and 422 is not part of the status codes (a list of the status codes which are part of DRF can be found here: http://www.django-rest-framework.org/api-guide/status-codes/#client-error-4xx)

404 also doesn&#39;t look right because the data is successfully accepted and not refused.

With that said, what is the real correct response which should be used?

What&#39;s the appropriate HTTP status code to return if a user tries logging in with an incorrect username / password, but correct format?

I am designing a RESTful web service that needs to be accessed by users, but also other web services and applications. All of the incoming requests need to be authenticated. All communication takes place over HTTPS. User authentication is going to work based on an authentication token, acquired by POSTing the username and password (over an SSL connection) to a */session* resource provided by the service.

*In the case of web service clients, there is **no end user** behind the client service.* The requests are initiated by scheduled tasks, events or some other computer operations. The list of connecting services is known beforehand (obviously, I guess). **How should I authenticate these requests coming from other (web) services?** I want the authentication process to be as easy as possible to implement for those services, but not at the cost of security. What would be the standard and best practices for a scenario like this?

Options that I can think of (or have been suggested to me):

1. Have the client services resort to having a &quot;fake&quot; username and password, and authenticate them in the same way as users. I do not like this option - it just doesn&#39;t feel right.

2. Assign a permanent application id for the client service, possibly an application key as well. As far as I have understood this is just the same as having username + password. With this id and key, I can either authenticate each request, or create an authentication token to authenticate further requests. Either way, I do not like this option, because anyone who can get a hold of the application id and key can impersonate the client.

3. I could add an IP address check to previous option. This would make it harder to perform fake requests.

4. Client certificates. Set up my own certificate authority, create root certificate, and create client certificates for the client services. A couple of issues come to mind, though: a) how do I still allow the users to authenticate without certificates and b) how complicated is this scenario to implement from the client service point of view?

5. *Something else - there must be other solutions out there?* 

My service would be running on Java, but I deliberately left out information about what specific framework it would be built on, because I am more interested on the basic principles and not so much on the implementation details - I assume the best solution for this will be possible to implement regardless of the underlying framework. However, I am a bit inexperienced with this subject, so concrete tips and examples on the actual implementation (such as useful third party libraries, articles, etc.) will be much appreciated as well.

RESTful web service - how to authenticate requests from other services?

I am using node with express + mongoose and trying to use passport.js with restful api.   
I keep getting this exception after authentication success (I see the callback url on the browser):

    /Users/naorye/dev/naorye/myproj/node_modules/mongoose/lib/utils.js:419
            throw err;
                  ^
    Error: passport.initialize() middleware not in use
        at IncomingMessage.req.login.req.logIn (/Users/naorye/dev/naorye/myproj/node_modules/passport/lib/passport/http/request.js:30:30)
        at Context.module.exports.delegate.success (/Users/naorye/dev/naorye/myproj/node_modules/passport/lib/passport/middleware/authenticate.js:194:13)
        at Context.actions.success (/Users/naorye/dev/naorye/myproj/node_modules/passport/lib/passport/context/http/actions.js:21:25)
        at verified (/Users/naorye/dev/naorye/myproj/node_modules/passport-facebook/node_modules/passport-oauth/lib/passport-oauth/strategies/oauth2.js:133:18)
        at Promise.module.exports.passport.use.GitHubStrategy.clientID (/Users/naorye/dev/naorye/myproj/config/passport.js:91:24)
        at Promise.onResolve (/Users/naorye/dev/naorye/myproj/node_modules/mongoose/node_modules/mpromise/lib/promise.js:162:8)
        at Promise.EventEmitter.emit (events.js:96:17)
        at Promise.emit (/Users/naorye/dev/naorye/myproj/node_modules/mongoose/node_modules/mpromise/lib/promise.js:79:38)
        at Promise.fulfill (/Users/naorye/dev/naorye/myproj/node_modules/mongoose/node_modules/mpromise/lib/promise.js:92:20)
        at /Users/naorye/dev/naorye/myproj/node_modules/mongoose/lib/query.js:1822:13

I have read that I should put `app.use(passport.initialize());` and `app.use(passport.session());` before `app.use(app.router);` and this is what I did. Here is my express.js that registers the middlewares:

    var express = require(&#39;express&#39;),
        mongoStore = require(&#39;connect-mongo&#39;)(express),
        flash = require(&#39;connect-flash&#39;),
        helpers = require(&#39;view-helpers&#39;);
    
    module.exports = function (app, config, passport) {
        app.set(&#39;showStackError&#39;, true);
        // should be placed before express.static
        app.use(express.compress({
            filter: function (req, res) {
                return /json|text|javascript|css/.test(res.getHeader(&#39;Content-Type&#39;));
            },
            level: 9
        }));
        app.use(express.favicon());
        app.use(express.static(config.root + &#39;/public&#39;));
    
        app.use(express.logger(&#39;dev&#39;));
    
        // set views path, template engine and default layout
        app.set(&#39;views&#39;, config.root + &#39;/app/views&#39;);
        app.set(&#39;view engine&#39;, &#39;jade&#39;);
    
        app.configure(function () {
            // use passport session
            app.use(passport.initialize());
            app.use(passport.session());
    
            // dynamic helpers
            app.use(helpers(config.app.name));
    
            // cookieParser should be above session
            app.use(express.cookieParser());
    
            // bodyParser should be above methodOverride
            app.use(express.bodyParser());
            app.use(express.methodOverride());
    
            // express/mongo session storage
            app.use(express.session({
                secret: &#39;linkit&#39;,
                store: new mongoStore({
                    url: config.db,
                    collection : &#39;sessions&#39;
                })
            }));
    
            // connect flash for flash messages
            app.use(flash());
    
            // routes should be at the last
            app.use(app.router);
    
            // assume &quot;not found&quot; in the error msgs
            // is a 404. this is somewhat silly, but
            // valid, you can do whatever you like, set
            // properties, use instanceof etc.
            app.use(function(err, req, res, next){
                // treat as 404
                if (~err.message.indexOf(&#39;not found&#39;)) {
                    return next();
                }
    
                // log it
                console.error(err.stack);
    
                // error page
                res.status(500).render(&#39;500&#39;, { error: err.stack });
            });
    
            // assume 404 since no middleware responded
            app.use(function(req, res, next){
                res.status(404).render(&#39;404&#39;, {
                    url: req.originalUrl,
                    error: &#39;Not found&#39;
                });
            });
        });
    };

What is wrong?

**UPDATE**
According to @Peter Lyons I have changed the configurations order to the following, but I still got the same error:

    var express = require(&#39;express&#39;),
        mongoStore = require(&#39;connect-mongo&#39;)(express),
        flash = require(&#39;connect-flash&#39;),
        helpers = require(&#39;view-helpers&#39;);
    
    module.exports = function (app, config, passport) {
        app.set(&#39;showStackError&#39;, true);
        // should be placed before express.static
        app.use(express.compress({
            filter: function (req, res) {
                return /json|text|javascript|css/.test(res.getHeader(&#39;Content-Type&#39;));
            },
            level: 9
        }));
        app.use(express.favicon());
        app.use(express.static(config.root + &#39;/public&#39;));
    
        app.use(express.logger(&#39;dev&#39;));
    
        // set views path, template engine and default layout
        app.set(&#39;views&#39;, config.root + &#39;/app/views&#39;);
        app.set(&#39;view engine&#39;, &#39;jade&#39;);
    
        app.configure(function () {
    
            // dynamic helpers
            app.use(helpers(config.app.name));
    
            // cookieParser should be above session
            app.use(express.cookieParser());
    
            // bodyParser should be above methodOverride
            app.use(express.bodyParser());
            app.use(express.methodOverride());
    
            // express/mongo session storage
            app.use(express.session({
                secret: &#39;linkit&#39;,
                store: new mongoStore({
                    url: config.db,
                    collection : &#39;sessions&#39;
                })
            }));
    
            // connect flash for flash messages
            app.use(flash());
    
            // use passport session
            app.use(passport.initialize());
            app.use(passport.session());
    
            // routes should be at the last
            app.use(app.router);
    
            // assume &quot;not found&quot; in the error msgs
            // is a 404. this is somewhat silly, but
            // valid, you can do whatever you like, set
            // properties, use instanceof etc.
            app.use(function(err, req, res, next){
                // treat as 404
                if (~err.message.indexOf(&#39;not found&#39;)) {
                    return next();
                }
    
                // log it
                console.error(err.stack);
    
                // error page
                res.status(500).render(&#39;500&#39;, { error: err.stack });
            });
    
            // assume 404 since no middleware responded
            app.use(function(req, res, next){
                res.status(404).render(&#39;404&#39;, {
                    url: req.originalUrl,
                    error: &#39;Not found&#39;
                });
            });
        });
    };

passport.js passport.initialize() middleware not in use

All the articles about GraphQL will tell you how wonderful it is, but are there any disadvantages or shortcomings to it? Thank you.

Are there any disadvantages to GraphQL?

Is using sessions in a RESTful API really violating RESTfulness? I have seen many opinions going either direction, but I&#39;m not convinced that sessions are *RESTless*. From my point of view:

- authentication is not prohibited for RESTfulness (otherwise there&#39;d be little use in RESTful services)
- authentication is done by sending an authentication token in the request, usually the header
- this authentication token needs to be obtained somehow and may be revoked, in which case it needs to be renewed
- the authentication token needs to be validated by the server (otherwise it wouldn&#39;t be authentication)

So how do sessions violate this?

- client-side, sessions are realized using cookies
- cookies are simply an extra HTTP header
- a session cookie can be obtained and revoked at any time
- session cookies can have an infinite life time if need be
- the session id (authentication token) is validated server-side

As such, to the client, a session cookie is exactly the same as any other HTTP header based authentication mechanism, except that it uses the `Cookie` header instead of the `Authorization` or some other proprietary header. If there was no session attached to the cookie value server-side, why would that make a difference? The server side implementation does not need to concern the client as long as the server *behaves* RESTful. As such, cookies by themselves should not make an API *RESTless*, and sessions are simply cookies to the client.

Are my assumptions wrong? What makes session cookies *RESTless*?

Do sessions really violate RESTfulness?

I&#39;m working on building a RESTful API for one of the applications I maintain. We&#39;re currently looking to build various things into it that require more controlled access and security. While researching how to go about securing the API, I found a few different opinions on what form to use. I&#39;ve seen some resources say HTTP-Auth is the way to go, while others prefer API keys, and even others (including the questions I found here on SO) swear by OAuth. 

Then, of course, the ones that prefer, say, API keys, say that OAuth is designed for applications getting access on behalf of a user (as I understand it, such as signing into a non-Facebook site using your Facebook account), and not for a user directly accessing resources on a site they&#39;ve specifically signed up for (such as the official Twitter client accessing the Twitter servers). However, the recommendations for OAuth seem to be even for the most basic of authentication needs.

My question, then, is - assuming it&#39;s all done over HTTPS, what are some of the practical differences between the three? When should one be considered over the others?

API Keys vs HTTP Authentication vs OAuth in a RESTful API

I&#39;ve been reading up on REST and there are a lot of questions on SO about it, as well as on a lot of other sites and blogs.  Though I&#39;ve never seen this specific question asked...for some reason, I can&#39;t wrap my mind around this concept...

If I&#39;m building a RESTful API, and I want to secure it, one of the methods I&#39;ve seen is to use a security token.  When I&#39;ve used other APIs, there&#39;s been a token and a shared secret...makes sense.  What I don&#39;t understand is, requests to a rest service operation are being made through javascript (XHR/Ajax), what is to prevent someone from sniffing that out with something simple like FireBug (or &quot;view source&quot; in the browser) and copying the API key, and then impersonating that person using the key and secret?

REST authentication and exposing the API key

The [JWT spec][1] mentions a jti claim which allegedly can be used as a nonce to prevent replay attacks: 

&gt; The &quot;jti&quot; (JWT ID) claim provides a unique identifier for the JWT. The identifier value MUST be assigned in a manner that ensures that there is a negligible probability that the same value will be accidentally assigned to a different data object; if the application uses multiple issuers, collisions MUST be prevented among values produced by different issuers as well. The &quot;jti&quot; claim can be used to prevent the JWT from being replayed. The &quot;jti&quot; value is a case-sensitive string. Use of this claim is OPTIONAL.

My question is, how would I go about implementing this? Do I need to store the previously used jtis and issue a new JWT with every request? If so, doesn&#39;t this defeat the purpose of JWTs? Why use a JWT instead of just storing a randomly-generated session ID in a database?

My REST API has a Mongo database and I&#39;m not opposed to adding a Redis instance. Is there a better authentication option than JWT? I mainly just don&#39;t want to store passwords on the client which eliminates HTTP authentication as an option, however, as I&#39;m getting deeper into this JWT stuff, I&#39;m starting to feel as if a custom token implementation or different standard might better suit my needs. Are there any node/express packages for token based authentication that supports token revocation and rotating tokens?

Would appreciate any advice.

[1]: https://www.rfc-editor.org/rfc/rfc7519#section-4.1.7

How to use jti claim in a JWT

I have to implement secure [RESTful web services][1]. I already did some research using Google but I&#39;m stuck.

Options:

TLS (HTTPS) +

 - HTTP Basic (pc1oad1etter)
 - HTTP Digest 
 - [two-legged][2] [OAuth][3]
 - [a Cookie-based approach][4]
 - client certificates (Tom Ritter and [here][5])
 - Signed requests using [HMAC][6] and [a limited lifetime][7]

Are there more possible options to consider? If OAuth then what version? Does it even matter? From what I&#39;ve read so far [OAuth 2.0][8] with bearer tokens (that is without signatures) seems to be [insecure][9].

I&#39;ve found another very interesting article on [REST based authentication][10].

[Secure Your REST API... The Right Way][11]


  [1]: https://www.ibm.com/developerworks/webservices/library/ws-restful/
  [2]: https://stackoverflow.com/questions/4239846/2-legged-oauth-and-rest
  [3]: https://github.com/Mashape/mashape-oauth/blob/master/FLOWS.md
  [4]: https://stackoverflow.com/questions/319530/restful-authentication
  [5]: https://stackoverflow.com/questions/1522368/solutions-to-web-service-client-certificates-auth-best-practices
  [6]: http://en.wikipedia.org/wiki/HMAC
  [7]: http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html
  [8]: http://tools.ietf.org/pdf/draft-ietf-oauth-v2-12.pdf
  [9]: http://hueniverse.com/2010/09/oauth-bearer-tokens-are-a-terrible-idea/
  [10]: http://www.berenddeboer.net/rest/authentication.html
  [11]: https://www.stormpath.com/blog/secure-your-rest-api-right-way

How to secure RESTful web services?

I am building a web application with a services layer.  The services layer is going to be built using a RESTful design.  The thinking is that some time in the future we may build other applications (iPhone, Android, etc.) that use the same services layer as the web application.  My question is this - how do I implement login?  I think I am having trouble moving from a more traditional verb based design to a resource based design.  If I was building this with SOAP I would probably have a method called Login.  In REST I should have a resource.  I am having difficulty understanding how I should construct my URI for a login.  Should it be something like this:

http://myservice/{username}?p={password}

EDIT: The front end web application uses the traditional ASP.NET framework for authentication.  However at some point in the authentication process I need to validate the supplied credentials. In a traditional web application I would do a database lookup. But in this scenario I am calling a service instead of doing a database lookup.  So I need something in the service that will validate the supplied credentials.  And in addition to validating the supplied credentials I probably also need some sort of information about the user after they have successfully authenticated - things like their full name, their ID, etc.  I hope this makes the question clearer.

Or am I not thinking about this the right way?  I feel like I am having difficulty describing my question correctly.

Corey

How do I implement login in a RESTful web service?

I&#39;ve been coding a RESTful service in Java. This is what I&#39;ve understood till now (correct me if i&#39;m wrong):

Token authorization is done using _JSON Web Tokens (JWT)_ which have three parts: the header, the payload, and the secret (shared between the client and the server). 

I understood this concept and stumbled over _JSON Web Signature (JWS)_ while reading about JWT.
 
JWS also is an encoded entity similar to JWT having a header, payload, and a shared secret.

**Question:** What is the difference between the two concepts, namely JWT and JWS? And if they are alike technically, then what&#39;s the difference in their *implementation*?

This is the first time I&#39;m working with token based auth, so it&#39;s possible I&#39;ve misunderstood the concept altogether.

P.S. I learned about JWS while browsing through the examples on [this website][1].


  [1]: http://connect2id.com/products/nimbus-jose-jwt

What is the difference between JSON Web Signature (JWS) and JSON Web Token (JWT)?

#Angular+RESTful Client-side Communication w/ API for Auth/(re)Routing

This has been covered in a few different questions, and in a few different tutorials, but all of the previous resources I&#39;ve encountered don&#39;t quite hit the nail on the head. 

##**In a nut-shell, I need to**

 * Login via POST from `http://client.foo` to `http://api.foo/login`
 * Have a &quot;logged in&quot; GUI/component state for the user that provides a `logout` route
 * Be able to &quot;update&quot; the UI when the user logs out / logs out. 
     *This has been the most frustrating*
 * Secure my routes to check for authenticated-state (should they need it) and redirect the user to the login page accordingly

##**My issues are**
 
 * Every time I navigate to a different page, I need to make the call to `api.foo/status` to determine whether or not user is logged in. (ATM I&#39;m using Express for routes) This causes a hiccup as Angular determines things like `ng-show=&quot;user.is_authenticated&quot;`
 * When I successfully login/logout, I need to refresh the page (I don&#39;t want to have to do this) in order to populate things like `{{user.first_name}}`, or in the case of logging out, empty that value out. 

   &lt;!--lang:js--&gt;
    
    // Sample response from `/status` if successful 

    {
       customer: {...},
       is_authenticated: true,
       authentication_timeout: 1376959033,
       ...
    }
 

##**What I&#39;ve tried**

* http://witoldsz.github.io/angular-http-auth/&lt;sup&gt;1&lt;/sup&gt;
* http://www.frederiknakstad.com/authentication-in-single-page-applications-with-angular-js/&lt;sup&gt;2&lt;/sup&gt; 
* https://github.com/mgonto/restangular (For the life of me I could not figure out how to `POST` with `post data` and not `query params`. The docs turned up nothing on the matter. 

##**Why I feel like I&#39;m losing my mind**

* It seems as though every tutorial relies on some database (lots of Mongo, Couch, PHP+MySQL, ad infinitum) solution, and none rely purely on communication with a RESTful API to persist logged-in states. Once logged in, additional POSTs/GETs are sent with `withCredentials:true`, so that&#39;s not the issue
* I cannot find ANY examples/tutorials/repos that do Angular+REST+Auth, sans a backend language. 

##**I&#39;m not too proud**

Admittedly, I&#39;m new to Angular, and would not be surprised if I&#39;m approaching this in a ridiculous way; I&#39;d be thrilled if someone suggest an alternative—even if it&#39;s soup-to-nuts. 

I&#39;m using `Express` mostly because I really love `Jade` and `Stylus`— I&#39;m not married to the `Express`&#39; routing and will give it up if what I want to do is only possible with Angular&#39;s routing.  

Thanks in advance for any help anyone can provide. And please don&#39;t ask me to Google it, because I have about 26 pages of purple links. ;-)

---

&lt;sup&gt;1&lt;/sup&gt;This solution relies on Angular&#39;s $httpBackend mock, and it&#39;s unclear how to make it talk to a real server.

&lt;sup&gt;2&lt;/sup&gt;This was the closest, but since I have an existing API I need to authenticate with, I could not use passport&#39;s &#39;localStrategy&#39;, and it seemed **insane** to write an OAUTH service...that only I intended to use. 

AngularJS Authentication + RESTful API

I could do with some help on my REST API. I&#39;m writing a Node.js app which is using Express, MongoDB and has Backbone.js on the client side. I&#39;ve spent the last two days trying to work out all of this and not having much luck. I&#39;ve already checked out:

 - https://stackoverflow.com/questions/2676241/securing-a-rest-api
 - https://stackoverflow.com/questions/4574868/securing-my-rest-api-with-oauth-while-still-allowing-authentication-via-third-pa
 - http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/
 - http://tesoriere.com/2011/10/10/node.js-getting-oauth-up-and-working-using-express.js-and-railway.js/

I want to keep my backend and frontend as separate as possible so I thought about using a carefully designed REST API would be good. My thinking is that if I ever get round to developing an iPhone app (or something else like that), it could use the API to access data.

BUT, I want this to be secure. A user has logged into my web app and I want to ensure my API is secure. I read about OAuth, OAuth 2.0, OpenID, Hmac, hashes etc... I want to avoid using external logging in (Facebook/Twitter/etc) I want the registering and logging in to be on my app/server.

...but I&#39;m still confused here. Maybe it&#39;s late at night or my brain is just fried, but I could really do with some steps on what to do here. What are the steps for me to create a secure API?

Any help, any information, any examples, steps or anything would be great. Please help!


All Restful Authentication Solutions on Gang of Coders

Total of 18 Restful Authentication Solutions

What does #self.included(base) do in Ruby on Rails' Restful Authentication?