Re: HTTP_AUTHORIZATION header

I need to know the AuthFlags setting in all the vdirs and URLs (if you used
IIsWebFile) involved.

You can configure IIS to not keep-alive with:
ADSUTIL.VBS SET W3SVC/AllowKeepAlive 0

In general, I do not like "testing" with browsers because it is hard to
determine if it is client-side caching/issue or server-side issue.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no rights.
//

"AWillemsen" <AWillemsen@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:42D3D5A7-899A-4AAF-B519-E07528227588@xxxxxxxxxxxxxxxx
David - Many thanks for your continued interest - it is appreciated.

I think I have got to the bottom of the problem. Apologies this is a long
message.

I have tried removing the pwsdata and ASP.Net ISAPI filters, and this
makes
no difference.

I have verified that the method of execution of the CGI - GET form, POST
form, or directly in the browser address - also makes no difference.

The two virtual directories do make a difference, as follows (each of the
following tests was performed in a new browser window):

1) Display HTML page in directory A (browser asks for credentials),
execute
CGI in directory B - failure (CGI reports AUTH_TYPE and AUTH_USER, but no
HTTP_AUTHORIZATION).

2) Display HTML page in directory B (browser asks for credentials),
execute
CGI in directory B - success

3) Execute CGI in directory B directly from browser (browser asks for
credentials) - success

4) And most strangely, display HTML page in directory B (browser asks for
credentials), execute CGI in directory A - success

Given the unexpected outcome of test 4, I looked at the differences
between
directories A and B. The IIS virtual directory configurations are
identical,
the NTFS permissions on the physical directories are identical, and the
physical directories exist side-by-side on the same drive. I then noticed
that a couple of images that are present in directory A are missing from
directory B. These images are used by the HTML page that I am displaying
in
the tests, so I copied them from A to B. Now test 4 fails too. In fact,
it
fails if just one of the images is present - only if both are missing does
the test succeed.

Now, I am even more confused than I was at the start. How can the
successful retrieval of an image when displaying an HTML page affect the
following execution of a CGI? I just don't understand, but that is what I
am
seeing.....

So, I continued digging.

1) If both images are referenced in the HTML page and both images exist,
then the 3rd execution of the CGI succeeds

2) If both images are referenced in the HTML page but only one image
exists
(it doesn't matter which one), then the 2nd execution of the CGI succeeds

3) If both images are referenced in the HTML page and neither image
exists,
then the 1st execution of the CGI succeeds

I tried changing the number of images referenced in the HTML page, and
referencing more than two made no difference (i.e. the behaviour was the
same
as with two). Referencing just one image led to the same behaviour as
point
2 above (i.e. if the image exists then the 2nd execution succeeds).
Referencing no images again led to the same behaviour as point 2 (i.e. the
2nd execution of the CGI succeeds).

For your information - all the above testing was done with IE6, and I
entered my credentials every time (i.e. I didn't ask IE to save my
details).

At this point I began suspecting my problem might have something to do
with
keep-alive connections, so I switched from using a browser, as follows:

1) The first alternative I used was some in-house software which has the
ability to retrieve from HTTP servers but does not use keep-alive
connections. I set up a configuration to retrieve the HTML page and then
execute the CGI, and success. (Note that this was different behaviour
than
what I saw in the browser.)

2) Next I tried Wfetch, and again success.

3) Then I tried Firefox, and it failed.

4) Finally, I switched off keep-alive connections in Firefox, and
success!

Unfortunately, I do not know how to switch off keep-alive connections in
IE,
if indeed it is possible, so I cannot test IE.

However, I think I can conclude that if using keep-alive connections is
somehow causing IIS to not send the HTTP_AUTHORIZATION variable. I have
also
shown that, to a certain extent, the number of items retrieved over a
keep-alive connection affects the number of times the HTTP_AUTHORIZATION
variable is missing.

You should be able to reproduce the problem by creating an HTML page that
contains both a form and references to two images in the same directory as
the HTML page. The form action points to a second directory. Then use IE
to
display the HTML page (supply credentials) and then submit the form. I
would
be more than happy to send you my HTML page, images and CGI if required.

Thanks,

Andrew



"David Wang [Msft]" wrote:

Well, let's see what we have here. You say:
1. your configuration is correct
2. you are fairly certain it is not the network nor proxy
3. it is not the application because it works fine on Apache
4. there are no custom ISAPI DLLs installed
--> So the issue must be an IIS bug

I say:
1. Given your repro steps, I cannot reproduce it
2. Given your observations, it does not make sense with any Basic/NTLM
authentication sequence. IIS cannot derive AUTH_TYPE and AUTH_USER
without
HTTP_AUTHORIZATION.
3. My XP Pro does not have pwsdata nor ASP.Net 2.0 ISAPI Filters
--> I think there is misconfiguration or custom code running somewhere

I'm pretty certain the form, POST, and two virtual directories are not
relevant to the issue, but you can verify. You should be able to
reproduce
this in your setup by directly accessing the CGI EXE a couple of timems.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no
rights.
//

"AWillemsen" <AWillemsen@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:82B422B8-3D84-4989-AB80-9CC41CA8285B@xxxxxxxxxxxxxxxx
I've installed Apache 2.0, and set up a mirror configuration to IIS,
i.e.
the
aliases point to the same physical directories. With Basic
authentication,
Apache works fine, i.e. the HTTP_AUTHORIZATION header gets sent every
time
to
the CGI.

The only differences between the two Web servers are as follows:

1) Apache is on port 8080, IIS is on port 80

2) Apache is using credential files, IIS is using the local user
accounts
(my machine is not part of a domain)

Thanks, Andrew


"David Wang [Msft]" wrote:

I cannot reproduce your claims on my XPSP2 IIS5.1 based on your
instructions. So, I believe your observations are isolated to just
your
network.

I used both WFetch and IE6.

I use WFetch to make a Basic authenticated POST request against my CGI
EXE
which returns HTTP_AUTHORIZATION (amongst many other server variables
and
environment variables).

My CGI returns HTTP_AUTHORIZATION on first and every response.

I see the expected HTTP_AUTHORIZATION on all IE6-based Basic requests,
too.

What I suspect is happening in your situation are:
1. Your server is not configured how you think. Make sure AuthFlags is
correct value for your URL
2. A misconfiguration in your networking. Maybe proxy server is doing
NTLM
for you somehow
3. A custom ISAPI Filter on the server that is munging the
Authorization:
header according to arbitrary logic

FYI: Nitpick on your stated understanding of authentication
protocols -
Authorization: header is not expected for every request for NTLM
authentication request.
- It is required for every Basic authenticated request (since HTTP is
stateless, the fact that one request is basic authenticated means
nothing
for the subsequent request, hence all requests must send
Authorization:
header for Basic authentictaion
- It is required for initial NTLM handshake and not required
thereafter
(NTLM uses TCP connection as state. Thus after first authenticated
request,
all subsequent requests over the same connection is considered
authenticated
and hence Authorization: header is not required for those subsequent
requests).

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no
rights.
//

"AWillemsen" <AWillemsen@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:21DD82C6-74A2-4EEC-8D77-33C2159BA543@xxxxxxxxxxxxxxxx
I do not believe IIS is distinguishing between the two cases you
mention.
If
I authenticate by displaying the HTML page containing the form, then
it
does
not matter whether I execute the form or type the address of the CGI
in -
both result in the HTTP_AUTHORIZATION header not being sent to the
CGI.
IIS
passes the AUTH_TYPE and AUTH_USER (for Basic) headers, so the
browser
has
definitely authenticated. But it does not pass the
HTTP_AUTHORIZATION
header
on the first form or CGI execution. This happens in both IE 6 and
Firefox
1.5, and on multiple client machines, so I don't think it's client
variation.
I have also tried it on two other server machines, both running IIS
5.0,
and
it happens there too.

I do understand the authentication protocols involved, and I do
expect
the
HTTP_AUTHORIZATION header to be sent on every request, regardless of
whether
Basic or NTLM is used. And this does indeed happen - once the
header
is
sent, it is always sent.

From what I've seen, this does appear to be a bug in IIS...


"David Wang [Msft]" wrote:

Can you explain how IIS can distinguish between you directly typing
in
the
address of the CGI in the address bar vs the FORM submit.

The answer is -- IIS cannot distinguish between those two cases.
Thus,
if
you see different behavior in those two situations, it's either
client-side
variation or misunderstanding of the authentication protocol
involved.

For NTLM, I do not expect HTTP Authorization header to be sent on
the
second
and subsequent requests after the initial negotiation completes.

For Basic, I expect the HTTP Authorization header to be sent on all
requests.

--
//David
IIS
http://blogs.msdn.com/David.Wang
This posting is provided "AS IS" with no warranties, and confers no
rights.
//

"AWillemsen" <AWillemsen@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in
message
news:47D24246-0A0F-4592-BA23-91A29232F5CF@xxxxxxxxxxxxxxxx
I am running IIS 5.1 on XP SP2. I have two virtual directories in
the
same
Web site that have anonymous access disabled - one contains HTML
pages
and
the other contains a CGI executable. One of the HTML pages has a
form
which
executes the CGI.

If I open a new browser window, and then open the HTML page with
the
form,
I
get asked for credentials (as expected). I then submit the form
which
executes the CGI. The first 2 times I do this, IIS passes to the
CGI
the
AUTH_TYPE variable with the correct value (Basic or Negotiate,
depending
on
which authentication scheme I have set up) but it does not pass
the
HTTP_AUTHORIZATION variable. The 3rd and subsequent times, both
variables
get passed.

Is this a bug in IIS?

Note that I tried authenticating against the CGI first, by
opening a
new
browser window and typing in the address of the CGI in the
address
bar.
This
asked me for credentials, as expected. If I then go to the HTML
form
and
submit it, the HTTP_AUTHORIZATION header gets passed to the CGI
every
time.












.

Relevant Pages

  • Re: HTTP_AUTHORIZATION header
    ... I have verified that the method of execution of the CGI - GET form, ... Display HTML page in directory A, ... authentication sequence. ...
    (microsoft.public.inetserver.iis.security)
  • Re: HTTP_AUTHORIZATION header
    ... I do not believe IIS is distinguishing between the two cases you mention. ... I authenticate by displaying the HTML page containing the form, ... both result in the HTTP_AUTHORIZATION header not being sent to the CGI. ... I do understand the authentication protocols involved, ...
    (microsoft.public.inetserver.iis.security)
  • Re: HTTP_AUTHORIZATION header
    ... address of the CGI in the address bar vs the FORM submit. ... The answer is -- IIS cannot distinguish between those two cases. ... Web site that have anonymous access disabled - one contains HTML pages ... browser window and typing in the address of the CGI in the address bar. ...
    (microsoft.public.inetserver.iis.security)
  • Re: HTTP Error 405-HTTP verb used to access this page is not allowed
    ... > passing a form from html to cgi page? ... As a client, is there an IIS ...
    (microsoft.public.inetserver.iis)
  • Re: CGI under IIS throws away printf on multiple posts.
    ... IIS is not throwing away anything. ... will have to implement in CGI, by taking a server-side lock to prevent the ... session from performing the operation a second consecutive time. ... "application session" (IIS is a high-performance server. ...
    (microsoft.public.inetserver.iis)
Quantcast