Hej Jean Baptiste,
>> There are a few interesting things with session id:
>> 1. monitor a continous session from an identified ip
>wow, I think linking IP and session is very dangerous. I won't do that.
It is done on the server side so this is no wow. It is never revealed to the
outside world.
>> 2. authentication
>OK, we're using session only for that.
If you do, then all activities (calls) enclosed by the authentication session
is a session!!!
>I try hard to maintain our server as stateless as possible for a future load
>balancing.
If it would be possible, but only without authentication it is true.
Authentication needs the session to
know that the user has been authenticated and still is logged in to be allowed
to call different functions.
>> 3. increased security
>> a) session cookies -> easy to break
>I didn't know that, could you explain ?
It can be stolen from the client or it can be tampered unencrypted during
transfer from server. It is a
one-time thing happening for a session.
>> b) jsessionid sent as a parameter -> securer and more difficult to tamper
>Why would is be more secure ? I don't see how ...
You can, if you want, create a dynamic change of the session id. It means that
the id sent from server to client
changes and is more difficult to tamper. It can also be encrypted. A little bit
more difficult to break. At least
not wide open doors!
>> We use sessions in the above mentioned way...and one more:
>> 4. identification for dynamically session dependent data requiring user
>> response
>Don't understand that point 4 ...
Not considering ordinary authentication, but if you want a captcha which is
bound to the session id
as the key of creating and storing it until validated.
>> 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.
>"within" ???
>Services can *access* session but are not store in session, what do you mean
>by "within" ?
Let us say enclosed. If you authenticate and the authentication is connected to
a session id all code
called after that is dependent on the session. The authentication opens the
door if you have the credentials.
But session (id) "signals" the time the door is open for the authenticated.
Session 1: We have the problem that we authenticate through an rpc service call
-> the door opens and slams after the rpc call has finished.
Session 2: When we call again a service for which we already in Session 1 has
been authenticated for, it is not open to be called without a new session id
given after a new authentication.
There is no session state survival!
We want the session state survival so it does not shutdown the session for
every call.
>> 1. new qx.io.remoteRpc() -> gives a connection and a session id kept all the
>> time
>Session are managed on server side, so I don't see how new qx.io.remoteRpc()
>could instanciate a new JEE session.
Of course it is on the server side! But the Rpc calls the server and
instantiates the first session.
>> 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.
>RpcJavaPOJO had been design to allow that. Parameters can be injected on
>server side, before the call to the service but outside client side scope.
Injection can be done by makeServerURL(instanceId) too in RpcJava and it seems
to be the only reasonable way to keep the session surviving.
>I hope this clarify that parameter injection and the design of our contrib.
As I have the expertise in Java I do understand it, but the manual you have is
too difficult to understand.
RpcJavaPojo is a good contribution. We tested it yesterday night again. It is
at least about 25% faster than
RpcJava and the integration is cleaner and better than RpcJava based on already
existing infrastructure.
Can I suggest you to make a better manual of your contribution and clarify with
better examples? Then
I think people might be more interested to use it.
Stefan
------------------------------------------------------------------------------
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
