Kyle, thank you for the effort on this library and making available. I have an application which uses almost the same stack. I was trying sapling but got the below error while following

1. ./scripts/development.sh to compile javascripts and css

The error is
$ ./scripts/development.sh
02 Oct 21:00:12 - error: Compiling of 'app/scripts/person/services.coffee' failed. rror: missing ] on line 50

I don't follow coffescript and would be nice to see it working locally.

thanks again.

@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": "[email protected]",
   "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': '[email protected]', '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": "[email protected]",
   "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': '[email protected]', 'password': 'pass1'}? Or maybe send the entire user object?

Option 3?

Thank you for your time,

Kyle