>It depends on the SOAP client. Most support cookies transparently - if they do nothing else is required. You'd just have to call some sort of Login method to get the cookie for the session started and then the client has to make sure that the sessoin stays alive.
Exactly.
>I can't offhand remember if the SOAP toolkit provides Cookie support (I think it does as does wwSoap). .NET also supports it, but I don't know how the client config for this works (I think it's done with a server side attribute on the Web service).
I succeeded last night to use low level API for Soap. I can then control everything from Visual FoxPro and pass the Session object as well if I need it. However, my test so far is that it doesn't bug when I create a cookie. However, when I want to read it such as lcCookie=Request.Cookies('Username'), it gives the type of lcCookie to be an object. I believe it might not be supported. IAC, I'll keep searching into that. I also discovered that the Session.SessionID is different at every call as oppose to when I call the same from a browser. From a browser, it gives me the same SessionID. But, when being invoked from a Web Service, it gives a new one each time.
>Bottom line is that something needs to track your login/login info. Cookies are the only 'generic' way that *might* be supported by the HTTP client calling your Web service. Anything else will require manual management.
If I can make it work, I'll let you know about it. There might be a reason why I get an object for the cookie. I also forces the client to request cookie. I have enabled SoapClient.ClientProperty("ServerHTTPRequest") = True but that still return an object for the value of the cookie.
>Some of these issues are part of what will get addressed in V2 of the SOAP spec that deals with automtic header handling for things like security and tokens (equivalent of sessions cookies).
Yes, this is what I've been waiting for since a while. :)
>FWIW, there was a good article on .NET Web services and session state a few months back in Visual Studio Magazine that discussed different approaches for Web Services to deal with tracking a user.
I read some of them as well last night from the net. I'll keep looking if I can find one that will unbreak that situation. :)
