Hej Jean Baptiste,
>On the backend, RPC should not be linked to session.
Backend = backend of client? ( I guess that is what you mean here ) The server
handles the session id.
Server:
The http request call first hits the rpc servlet in the server. This servlet is
always connected to a session id. I can not control that!
>Session should be managed on server side before reaching RPC.
It is. As described above.
There are a few interesting things with session id:
1. monitor a continous session from an identified ip
2. authentication
3. increased security
a) session cookies -> easy to break
b) jsessionid sent as a parameter -> securer and more difficult to tamper
We use sessions in the above mentioned way...and one more:
4. identification for dynamically session dependent data requiring user response
Alt 4 is very important to identify the user response and to validate it.
>RPC services are classes that should be singleton, no need to instanciate more
>than once, and this instance should be reached by thread, like a Servlet,
>inside or outside session, this should not be linked.
Singleton yes, but they are always within a session.
>Once you managed HTTP/JEE session before reaching RPC, in a filter for example
>or in your RPC servlet but before the RPC lib provided by the RPCJava contrib,
>you can do what you want and JEE is very simple for that.
It is the RpcServlet answering the http request call.
>On the client side, you don't have to pass the jsessionid token or anything
>else, this is all automatic from Java point of view.
Yes, by cookies but it can be more easily tampered.
>On each HTTP request, all cookies are passed (this is due to HTTP protocol)
>and that's how jsessionid is transferred and how Java handle it for you on
>server side.
yes, it does.
Well, every new rpc service call generates a new session id! This is the
problem! This is the situation we would like to be:
1. new qx.io.remoteRpc() -> gives a connection and a session id kept all the
time
2. rpcConnection.callServiceListeners(...) -> using the same session id as in
1) (this does NOT happen)
Being able to include a sessionid (or other data) inside the RPC payload but
not as part of the RPC method signature woulkd be great. There-by allowing you
to not have to include the
session identifier as part of EVERY single RPC method signature and
pushing security implementations into your serverside API.
>That way, you can use session in the service without problem but I would
>advice not to do so to maintain service independent from the underlying techno.
I agree to make things less dependent but security is more important.
>I advice to pass extra param to the service : the needed value you find in the
>session become function param that are pass to the service at the entry point
>of the server side.
yes, can you give an example of how you would do that?
>That way, this extra param are not seen as param from the rpc client side but
>the session do not pollute service that can stay functional/business things.
Can you explain what you mean here?
We did look at the RPCJavaPOJO 6 months ago but we didn't think it was stable
enough. We did notice that it was faster than RpcJava. We also noticed that it
was easy to switch between them. Additionally, we missed the session id
injection as in RpcJava.
Stefan
>By the way, we gave a contribution called RPCJavaPOJO, a very ugly name for a
>good contribution ;-)
This Java RPC is more open and configurable than RPCJava (and also quicker) but
the software architecture assumption differs.
We are working at attribute level and not using accessors for RPC which is good
practice.
This allow the code to rely on transient Java keyword that apply to attribute.
This allow not to have accessor only for RPC but only because it is needed :
putting accessor everywhere simply break encapsulation.
Finally, you can have accessor or not : no impact on RPC.
To avoid serialization, use transient, it is there for that purpose.
Serializable classes must implement standard Serializable interface, this is
the only constraint we have.
------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
qooxdoo-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/qooxdoo-devel
