Handling Sessions

[kylefinley]

@DjebbZ, All,

I have made some updates to the project, and I'm now at a crossroads, and I would like to get your input.

It seems that there is basic user information that will be required for the majority of requests. This information consists of:

• displayName
• profilePictureUrl
• isAuthenticated
• isAdmin
• roles ?

I think that there are two ways to store and access this information:

Option 1:

When the app starts make a request to {API_BASE_URL}/users/me which will return a User object for the logged in user:

{
  "name": {
     "givenName": "Kyle",
     "familyName": "Finley"
   },
   "email": "test@example.com",
   "password": {
     "isSet": true
   },
   "roles": ["admin", "mod"],
   "profilePictureUrl": "...",
   "isAuthenticated": true,
   "isAdmin": true,
   // ... additional user related properties
   "catsName": "Captain Whiskers",
}

Pros:

• One request
• User object will be populated, so when showing extended profile information ('birthdate', 'urls', ect.) a request will not be needed.

Cons:

• The object returned will be larger then is need for most tasks.

Option 1-a:

If using option 1 -- how is the password authenticated?:
POST /auth {'email': 'test@example.com', 'password': 'pass1'}?

Option 2

When the app starts make a request to {API_BASE_URL}/sessions/me which will return a session object for the logged in user:

{
  "displayName": "Kyle Finley",
   "email": "test@example.com",
   "password": {
     "isSet": true
   },
   "roles": ["admin", "mod"],
   "profilePictureUrl": "...",
   "isAuthenticated": true,
   "isAdmin": true,
   // ... any additional session related data, which could be anything.
   "shoppingCart": [...]
}

When more detailed user information is need make a request to {API_BASE_URL}/users/me

Pros:

• Smaller initial request.
• A session (or way of storing arbitrary data) will probably be needed for other tasks anyways.

Cons:

• For more specific user information an additional request must be made E.g. /users/me
• More care must be taken to insure that information is synced between the session and the user i.e. if the user changes their displayName it must be updated in both the user and the session.

Option 2-a:

If using option 2 -- how is the password authenticated?:
POST /session {'email': 'test@example.com', 'password': 'pass1'}? Or maybe send the entire user object?

Option 3?

Thank you for your time,

Kyle

[DjebbZ]

I don't know a lot about sessions, but the way I'm building an Angular app now looks like Option 1 : retrieve a complete user object and store it in a user service. Why ? It reduces HTTP requests and sync overhead.

It also happens that I'm using a service named auth too to authenticate the user. But I'm authenticating against an external web-service (Singly), so I don't deal with passwords at all. My auth Angular service just retrieves the token granted by Singly, that I store in session when successfully connected.

Another point. I don't if having a stateless server is your objective, but storing a session in the server goes against this principle, since you can't scale horizontally (your user have to user the same server all along his session).

My 2 cents.

[kylefinley]

@DjebbZ Thank you. that was very helpful. You mentioned Singly before, but I overlooked that use case when I rewrote things. I'll bring the "auth" module back. I had removed it hopes of simplifying the authentication process.

Stateless: Keeping the server stateless is definitely a priority. I was think that session would be stored in memcache, datastore, or encrypted cookie, thereby being synced between instances.

Thanks again for the feedback, sorry for the late response.