Authentication

Current Authentication strategy

For the time being we are taking a rather simplistic approach to authentication. There are quite possibly some bad practices here, which we’d like to be made aware of!

When a user logs in a session is created by the system and stored in couchdb. The client is redirected to a resource representing that session, and the session token is also added to the client’s cookies. Whenever a client tries to access any part of the site the system checks for a valid session token in the Authorization: http header, and then in the cookies, and then pulls the session out of couchdb.

Cookies

The session token is stored in the rftr_session_token cookie

Authorization HTTP header

A client can optionally send their session token within the Authorization HTTP header, using a custom ‘RFTR_Token’ scheme. A typical header would look like this:

Authorization: RFTR_Token 3e4c33bdd92feae8be0f7824886bb531

Handling Authentication failures

• If a client requests an HTML representation of a resource and does not supply a token they will be redirected to the login page
• If a client requests a non-HTML representation of a resource (e.g. json, xml) they will be shown a 401 Unauthorized error response
• If a client provides an invalid token (by header or by cookie) they will be shown a 401 Unauthorized error response

Authenticating with curl

To authenticate you can use:

curl http://localhost:3000/sessions.json -d “user_name=rapidftr&password=rapidftr”

which should return a json representation of the session you just created, including the session id. Then you can use commands along the lines of:

curl -H “Authorization: RFTR_Token 3e4be58e2a2c314ad46b646bee4a4126” http://localhost:3000/children.json

to access resources that require authentication. Obviously you should replace that session token with the one returned by your initial POST to the sessions resource above.