Hej Jean Baptiste,
>I think there might be a wording problem : after reading your email, I'm not
>sure what you call a session is a JEE session but might be more a concept you
>implemented in your system that look like to be higher level than JEE session.
>If session is a JEE session, I feel dangerous (or at least meaningless) to
>link the client IP and that JEE session.
If the session and the ip "linked" to each other is shown to the outside world
by:
1. including it in the url sent back and forth
2. or kept in a way open
It is not good!
but it is already there...
when the server sends the cookie to the client you get the session id and if
you listen to the ip it is sent to, you have both!!!
...no difference!
>> If you do, then all activities (calls) enclosed by the authentication
>> session is a session!!!
>Our JEE session contain only authentication info and in the future, I'm
>looking for other technical way to ensure authentication so I can get ride of
>JEE session and be fully stateless.
>RPC calls are not "enclosed" in session. An authentication filter handle
>authentication (currently using session) and the request never reach RPC if
>not authenticated.
>Doing so in a independent filter make RPC services fully independent of
>authentication : pure business.
Well look here:
1. you authenticate -> a session is created -> a variable like "boolean
authenticated = true;" is saved as an attribute to the session!
2. you try to access an rpc service -> authenticated ? ->
if(Session.authenticated) -> execute the service
Authentication: This means that you have to have the SAME session else you can
NOT test the authenticated boolean for true!
This also means that the authentication "layer" with the session encloses the
rpc services, which need authentication to be called.
It means that the session must be alive. Our problem is that the session is not
alive. For every new call to a rpc service from the same
ip it gets a new session. We want the session id (created by the server)
connected to the first call when Rpc() establishes a connection with the server.
If you use jboss look at this:
http://community.jboss.org/wiki/HAWebSessionsviaDatabasePersistence
>> >> 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!
>>
>OK but new jsessionid imply new JEE session and you'll have to transfer
>content of old session to new one, interesting idea since JEE session contain
>only one very small object.
Japp
Didn't you have the following problem:
var rpc new qx.io.remote.Rpc() -> session id 1
rpc.callAsyncListeners(...) -> session id 2
rpc.callAsyncListeners(...) -> session id 3
....
i.e. one new session id for every call = no persistence!
But, how did you solve session persistence in the java web server for
authentication?
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
