axis-java-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Werner Dittmann <Werner.Dittm...@t-online.de>
Subject Re: [VOTE] [Axis2] Sessions on by default?
Date Mon, 02 Jan 2006 10:02:47 GMT
All,

just some additional thoughts regarding the session topic. Not only
technical but also more "social behaviour" abot the topic.

IMO the idea to have the client handle transport sessions by default
if the  server demands it could be a good idea. I specifically said
_could_ because I've some concerns about
- privacy
- technical reasons

Privacy:
Web services will be used more and more, become ubiquitous as browsers
are today. Enabling the client to handle e.g. cookies by default would
also enable the server to switch it on/off and use it. The user of the
client isn't even aware about this fact. Thus a server may track the
client's behaviour. This is the reason why all modern browsers allow a
user to control "sessions" (cookies). IMO this should be true for
webservices - let the programmer/user decide if the client needs or
supports sessions or not. If they are switched on by default then issue
a warning in big red letters.

Technical reasons:
If a service needs a session, even a transport session, then there must
be technical reasons behind this requirement. Then it is expected that
the client needs to contact the server more than once and the server
needs to identify the client or needs to know that the client called
again. This is a specific behaviour of the client - calling a service
more than once and the need to be identified by the service. In this
case the designer/programmer/user of the client can switch on sessions
explicitly. In all other cases sessions aren't needed and could be
"exploited" by malicious servers -see remark above.


Regards,
Werner


Sanjiva Weerawarana wrote:
> On Sat, 2005-12-31 at 07:29 +0000, Paul Fremantle wrote:
> 
>>I know I'm late :)
>>
>>Here are my views:
>>
>>1) Server sessions should be enabled by actual specific action of a
>>developer or deployer
>>
>>2) Client sessions should be enabled by the following model:
>>   a) If the programmer repeatedly uses the same instance of the same
>>stub then sessions will be *possible*. 
>>   b) Only if the server uses HTTP cookies or WS-A reference params
>>the session will be *actual*.
>>
>>i.e. for a session to take place, the consumer has to program in a
>>certain way AND the provider has to enable sessions. 
> 
> 
> Right. I think we're agreeing:
> 
> - service's scope should be set by the user and the default can be
> application
> - client (stub instance) by default should, *IF* cookies show up on the
> wire, use them. If they don't nothing happens. 
> 
> In order to support that behavior, the stub should be default be
> configured to copy cookies from responses and send them back on
> requests. If the server doesn't send them nothing happens.
> 
> Sanjiva.
> 
> 


Mime
View raw message