I have a windows application that connects to a web service that we've just rolled out to a new client. The application is throwing a 401 access denied error when the application is trying to connect to the web service.
Some things I've tried: I tested that the user ID and password are correct by installing the application on a few of our home computers. All of them succeed with the right credentials entered and fail properly with bad login information (straight up home installs with no VPNs or anything). I have verified the login and password are entered correctly by the client (I had the app dump the text for me to verify). I have verified that the client can point IE to the web service's URL, which properly authenticates with the login and password. I wouldn't necessarily think that a 401 error would result from this, but I did notice that their browsers have proxy autodetect turned on. I did some research to see if that was something I would have to implement. When I looked at assigning a proxy object to the Proxy property of the web service generated code, I get a deprecated message that says I should just use the proxy object that is automatically provided. Does that mean that the framework and the generated web service wrapper code from Visual Studio is smart enough to query the registry and detect web proxies? I created a form to dump out some of the settings as they exist on that machine and it appears that the Proxy property of the web service instance is null. Does anyone think the proxy is my problem, or should I keep looking? If it is the proxy, should the framework handle this out of the box or is this custom implementation? Is it possible that the proxy is stripping my credentials from the soap request and is there an obvious difference between my app creating an authenticated connection to the web service URL and the client's web browser making an authenticated (challenge/response) connection to the exact same URL? Thank you all!
