Glacier2/ identity

in Help Center
Hi there,
I am currently taking a deeper look into Glacier2, especially into the SessionManager functionality.
The implementation itself is quite straightforward, you've done that very well! What I'm missing is how I can find out the current user identity within arbitrary server calls. Also, it'd be interesting to find out the currently used identity on the client.
Is this possible?
cheers,
Stephan
I am currently taking a deeper look into Glacier2, especially into the SessionManager functionality.
The implementation itself is quite straightforward, you've done that very well! What I'm missing is how I can find out the current user identity within arbitrary server calls. Also, it'd be interesting to find out the currently used identity on the client.
Is this possible?
cheers,
Stephan
0
Comments
http://www.zeroc.com/vbulletin/showthread.php?t=1370
By making the facade accessible only to the authorized user (if you have one facade object per logged-in user, which also serves as session object), you can securely pass the user id to the back-end services as parameter.
As an alternative method, we could add an option to Glacier2, so that it adds the user-id to the context. While this would work, I'm not sure if I would recommend to use this method. If a user-id is required by a server, then this fact should be explicitly stated in the contract (i.e., in the parameter list of an operation expressed in Slice), instead of hiding this in the context.
Thanks for the answer and the pointer to the second Glacier2 thread.
However, I still do not get it
My session manager looks like this:
which means that I follow the principle you mentioned: I use the session object both as session object and "identity facade object" and set the category to meet the user name, following section 39.5.2 in the manual (Glacier2.AddUserToAllowCategories=2).
What I now don't yet get is how I can retrieve this identity on the server side.
Should it appear in the standard current parameter as current.id.category ?
regs,
Stephan
Wouldn't it be a nice addition to Glacier2 and Ice in general to show the caller's identity on the server without passing the session context explicitly?
This would significantly ease the development with Glacier2 as one wouldn't have to store the session proxy on the client as a global object and pass it with every server call. Furthermore, a pure-server side function for identity retrieval could be extended in the future for further functionality, e.g. for implementing a groups and roles model on top of it.
regs,
Stephan
Sorry, that still isn't correct. The client calls on the facade, the facade calls on the server backend. The facade stores the client-side session information, and passes it where necessary to the server backend or alternatively provides a method to get the data for the server back-end on demand.
The client does not need to pass its identity in every invocation.
Regards, Matthew
If I have a server object publishing the sayHello(name) function, i.e. implementing in turn:
string HelloWorldI::sayHello(string name, Ice.Current current) {}
How would the facade and the client call look here?
The implementation for move might be something like:
The facade itself has state and behaviour (in this case it knows whether the character is dead, and does some exception translation). The facade in this case has a member _character, which is assigned when logging in. A character knows its own identity, and thus its not necessary to use a parameter on invocations.
The facade also uses AMD/AMI chaining to ensure that threads are not held for an extended period of time by the client (see the article I wrote in connections for more information on this).
Hope this helps.
Looking at your example, I understand that all server functions are implemented twice, one time in the facade, adding session information and timeout behaviour (move_async() in your example) and another time in the backend, implementing the functionality itself (called through _character.moveToPointForClientClick_async(amiCB, info); in the example).
While this is ok for smaller server objects, I ask myself about the complexity that arises when having more interfaces on the server, each a number of functions.
Is my guess correct that you suggest to implement a facade function for all server-side functions in the mentioned interfaces?
Stephan
- It means that any mischief that a client can do (maliciously or due to a bug) is restricted to what the facade permits it to do. This also adds a layer of security, since the client is incapable of calling on non-facaded objects (due to Glacier2 access control).
- It presents a simple and direct interface to the server backend, that is free of any abstractions that the backend may contain.
- The backend server interfaces and implementation can change without affecting the client.
If you only have a small project, most of this stuff isn't necessary. But for a project of any complexity all of these advantages are significant -- especially if you have different teams for the server & client. The facade presents a contract between the server & client development teams. The client team doesn't need to understand all of the complexity offered by the server backend.
So to be specific:
It is not correct at all to say "all server functions". As I say above the facade probably presents only a subset of the full server functionality. As the complexity of the server backend rises the more value the facade itself can present both in protecting the server backend, and providing a more suitable abstraction for the "client". For the game in fact there were actually many different types of clients (and each had their own corresponding facade). There was the client that players used (ie: graphical front end), then there were administrative clients (user management), and GM clients (extra game administration).
While this would be easy to add, I'm reluctant to do so. Real-world Glacier applications are usually much more complex, and require a facade approach for the reasons Matthew explained. By adding such a feature, we would encourage to skip the facade approach, which will lead to many problems as the project grows.