>>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.
Well, this means either that the object needs to stay alive or the instance of the application must stay running. If WinInet/IE is used the Inet session attaches itself to the process it's hosted in so Cookies persist even across object instantiations. In .NET it's Object bound so as long as the object's alive and its internal cookie store live it's psased forward. Kill the object the cookie store goes with it. SOAP toolkit - I think this a low level feature meaning you have to write a bunch of code. wwSOAP uses WinInet so it's automatic.
>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.
All the collections return variant objects. You need to use Rquest.Cookies().Value
>>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. :)
Just realize this does nothign for your SOAP Toolkit clients/server issues. <s>