> Then it's not really a session id that's needed, but rather, a client id?
Well, if you want to have result sets persist over sessions, then I guess
so. But then you're really just saying that a session can last for an
indefinite amount of time.
My suggestion would be: When a client connects, if a session id is not
supplied, then it generates a new one and returns it. Otherwise resume the
previous session. Then if the client choses to retain the id somehow, it
becomes a client id, but there's no way to mandate this behaviour
Session IDs IMO should go as a Must Understand SOAP header, but could
equally be part of the XML proper.
(The reason I bring this up is that I just wrote an implementation of SOAP
and this sort of thing was an issue for one of my projected uses)
> > > Not so. In SRW (unlike Z39.50) the result set name is really a result
> > > set identifier generated by the server rather than requested by the
> > > client. So in SRW the result set name effectively acts as a session id.
> > Yes. But if they persist, which they must in some form, then they can be
> > operated on.
> > For example, I send to client A a result set named 'rs1'. The rogue DDOS
> > client then sends me a request against a result set named 'rs1' which
> > promptly disappears for the real user.
> > In the time between the server sending the resultset name to the client, a
> > different attacking client can send a request which uses that name. You
> > simply can't avoid that. You need to have a way of determining if the
> > client is allowed to operate on that result set.
,'/:. Rob Sanderson ([log in to unmask])
,'--/::(@)::. Special Collections and Archives, extension 3142
,'---/::::::::::. Twin Cathedrals: telnet: liverpool.o-r-g.org 7777
____/:::::::::::::. WWW: http://liverpool.o-r-g.org:8000/
I L L U M I N A T I