Improve the Auth generated by amber g auth

[crimson-knight]

The current authentication provided by the generator is too basic. The current auth uses the user_id as the session ID. Let's improve the generator to do the following:

• If a "user" model already exists, append the method information to that model instead of overwriting it
• If a "user" model already exists, make the generated migration an "alter table" instead of "create table" migration
• Add two new columns: session_random_token with type VARCHAR & session_expiration_date with type TIMESTAMP
• Make the session_token = used_id + session_random_token
• Change the sessions controller to set the session to use session_token and set the token into an in-memory data store
• Change the auth pipe from using a DB query to check for the existing user_id, check the in-memory data store for the session token that is provided.

The in-memory data store is probably best represented as a Hash(String, User)

{
  "kjlh01nv081304813408934": User
}

The session_token is going to require some parsing in order to do a database lookup in the event that the session token is not found. The idea here is that the session_token should be "#{session_random_token}:#{random_string}" where random_string is a randomly generated 64 character long string of mixed uppercase, lowercase and numbers.

[robacarp]

Good changes. You'll certainly want to make the relationship between Users and Session tokens a "has many" however you'd like to go about that. I don't really think there's a need to make the session token anything but a secure random string.

[crimson-knight]

@robacarp that's a good point of refinement, I was shooting for a single session allowed at a time, but that doesn't make sense even for my own use case, ha!

Since I'm building a mobile app, I want multiple sessions up to the device limit. So that's definitely a has_many kind of relationship.

So far I have the single token & single session working and using an in-memory cache that is managed by the Amber::Server class, but it's a basic Hash(String, User) setup. Which will probably get too inefficient at volume. because the keys are not sorted at first.