>It might be better to use Session info to track users, rather than SOAP headers. This way you can have people call your Login() type function, then just track the rest on the server. You may need to have a scheme that uses unique keys to make sure you can't spoof auth, but otherwise this is pretty easy to do.

How do you accomplish this? I assume that a table has to be created to keep the reference of a session on the server. That's probably the easiest part. Then, if the session is still active, that means, I'll be able to retrieve that record in that table and know who is behind the keyboard. However, how do I activate a session for the client side, once the Login() is successfull and how do I recognize that for every incoming transactions?

>The only other issue with this is that the client must support cookies. WinInet and wwHTTP (which is what the SOAP toolkit uses) supports this. With .NET I think there's an attribute you have to set on the Web service to specify that it will require session state (which in turn results on teh .NET client Web reference supportnig cookies).

Is a Web Service developped by Visual FoxPro able to work with a session?

>The other alternative is to use standard Authentication. Which means that the user must provide a property on the Web service that sets his username/password (in .NET using the .Credentials property on the Web reference). This is much cleaner but requires that you use one of the provided security providers. In .NET this is easy because you can use either NT accounts or a custom list of users configured from the config files - however there's no way to dynamically validate against a dynamic datasource like a table.

Our approach remains direct to Visual FoxPro tables. So, we will look at the session cookie.