On Fri, 6 Aug 2004 08:09:02 -0700, "Robin Chatterjee"
<RobinChatterjee (AT) discussions (DOT) microsoft.com> wrote:
Quote:
My environment is
1. In the Webconfig i have
authentication mode="Windows"/
identity impersonate="true"/
2.<authorization
allow users="user (AT) something (DOT) com" /> ( which is a Windows user)
/authorization
2. I enter a user name and a password of a windows users in the Web Server
in the Login screen
I made a Web reference to the Service
3. My login.aspx has the code
Dim WebSvc As New something.www.serviceName
WebSvc.Credentials = New Net.NetworkCredential(TextBox1.Text, TextBox2.Text)
WebSvc.MethodName()
Thats the whole scene. Pls explain where i am going wrong with a solution. I
do not want to give anonymous access in any way. |
We had a customer with what might possibly be the same situation, and
I don't really understand why the fix they think corrected it actually
did so, but I'll post it here and maybe we'll both learn something.
Their scenario was they installed our packaged app on .Net Framework
1.1 for the first time (after running on Framework 1.0 for the last
year or so successfully). They found that clients to our web services
interface failed with a 401 Access Denied, even though they SHOULD
have been successful, and were working just fine when the server code
was running on top of the 1.0 framework. They have the web.config for
the web services root set to Windows authentication (ie they did with
1.0 and still did when they upgraded the server to 1.1).
Anyway, what they did and they believe it corrected it to start
working again under 1.1, was to enable HttpGet and HttpPost for the
web services (as per kb article 819267 -
http://support.microsoft.com/default...;en-us;819267), viz:
<webServices>
<protocols>
<add name="HttpGet"/>
<add name="HttpPost"/>
</protocols>
</webServices>
As I said, I don't really understand why this is necessary, and I
don't think it is desirable. We don't have those additional verbs
configured on our demonstration server and none of our other customers
running under 1.1 have the same problem - I can't imagine none of them
are using Windows authentication to lock down the web services
interface, but maybe that is the case. My confusion about the issue is
that the clients should be using the SOAP protocol (rather than Http)
and that verb is fine with the default 1.1 configuration, and hence
those additional verbs simply should not be needed in a production
configuration with normal .Net code running on both sides of the web
services link.
I am currently following-up with this customer any other changes that
may have been made on the box they run our software on (ie aside from
the above), because it's not immediately obvious to me how their
change might make web services calls (from a 1.1 .Net web services
client to server, using Windows authentication) work any better or
worse.
Maybe the above will help in your situation too. Maybe someone wiser
than me can explain it (ie if indeed HttpGet and HttpPost DO need to
be enabled for web services authenticated in Windows mode under .Net
1.1), and we'll both learn something
ted.h.
--
Ted Harper (Sydney, Australia)