Support session variables

[therealbstern]

Right now, this module only supports authentication. Once that's out of the way, we can start looking at session variables (which might cause more lifetime problems).

[therealbstern]

This is a little out of scope; session variables are probably better handled by the owner.

[jolhoeft]

One thing that is currently a little awkward is support for anonymous sessions. Would a connection struct that contained a SessionId and an Option<String> (for username) be useful? This struct would be readily hashable, so could easily used as a key into a session data collection. Applications not supporting anonymous sessions just reject anything with None for a username.

[therealbstern]

Hmm. I suppose it's possible to tell them apart, but it wasn't what I was expecting. This is probably worth doing, though.

[jolhoeft]

The user isn't logged on. They just connected, and we issued them a `sessionId`, and we'll remember and expire it like any `sessionId`, but they are anonymous. Anonymous sessions could have data associated with them, but when the session expires, that data is essentially lost.

[therealbstern]

... We don't track the username right now. What you really want is a policy that allows anonymous logins. Right now, our naive policy allows this. I think this is application-level.

[jolhoeft]

We track the user that is associated with a ConnectionSignature, which is returned by the run method. That can be used as a key to store session information, although it can change, so is awkward on the application side. The get_user method returns the user logged in on that session, if any.

What I am thinking of is something to replace the run method, say get_connection, that returns an enum:

enum ConnectionType {
  Anonymous(ConnectionSignature),
  LoggedIn(ConnectionSignature, String),
}

We include the ConnectionString in the logged in case so the application can migrate information after the user logs in (or more likely, creates an account).

This can all be done on the application side now, but is a bit messy, and seems a common use case.

[therealbstern]

Hmm, this seems pretty reasonable. Do you want to grab it or should I do it?

[therealbstern]

I think it's a different issue, though. This issue is really for session variables.