I was wondering if anyone knows if the ClientSession’s identity (aka the value returned from getName()) MUST be unique? I notice that each ClientSession object has a ClientSessionId which appears to be unique. But does the identity also have ot be unique with a game? (Aka does the ClientSession get persisted using the sessionid or the identity?
The name is provided by the authenticator, (The entire internal Identity object actually is. That will make more sense when you have the document on writing Authenticators that I’m writing now.) So the answer to your question is that it is completely up to the policy of the authenticator.
A ClientSession and everything relating to it is only valid for the life of the session. So while it is unique at a point in time, its not necessarily historically unique.
If you want a unique identifier other then name, it should be provided by your authenticator in an extended Identity object that you use a custom manager/service pair to read. Again, this is all in the doc I’m writing now.
Does that make sense?
Yes but maybe I ought to change the way I ask the question. What would I lose if the name was not unique? I was thiking about doing the authentication at the application level rather than extending the stack by building my own Authenticator like discussed in anoher thread. However, I would still use the SimpleClient’s basic authentication I would simply always return the client type for the userid and a null password. Obviously if I used a null password I would use the NullAuthenticator.
But by doing that I could have dozens of ClientSessions all with a getName() of say “Full” or “Demo” as an example.
I guess it would make it impossible to bind the old ClientSessionListener with the new ClientSession as I would have no way to locate the ClientSessionListener until after the binding had already occured in the AppListeners.loggedIn() method. Is there any other issues I might encounter?
Thats basically it.
Note though that if you didn’t want to store info about a DEMO user this would be no problem.
You would simply special case a user name of “demo” or “guest” and create a new, unbound ClientSessionListener ManagedObject for everyone who joined that way and remove them from the ObjectStore on disconnect.
About the only other issue I can think of is that, currently, if your reject a user by returning null from loggedIn rather then by rejecting in the authenticator you cannot pass a “reason” string back to the client.
Oh and DONT use disconnect() in loggedIn(). Thats wrong and will make odd thinsg happen in the current release. To reject the user just return a null ClientSessionListener
Ahhh some very good points.