|
security
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
HTTP_AUTHORIZATION headerWeb 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. 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. -- Show quoteHide quote//David IIS http://blogs.msdn.com/David.Wang This posting is provided "AS IS" with no warranties, and confers no rights. // "AWillemsen" <AWillem***@discussions.microsoft.com> wrote in message news:47D24246-0A0F-4592-BA23-91A29232F5CF@microsoft.com... >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. > 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... Show quoteHide quote "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" <AWillem***@discussions.microsoft.com> wrote in message > news:47D24246-0A0F-4592-BA23-91A29232F5CF@microsoft.com... > >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. > > > > > 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). -- Show quoteHide quote//David IIS http://blogs.msdn.com/David.Wang This posting is provided "AS IS" with no warranties, and confers no rights. // "AWillemsen" <AWillem***@discussions.microsoft.com> wrote in message news:21DD82C6-74A2-4EEC-8D77-33C2159BA543@microsoft.com... >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" <AWillem***@discussions.microsoft.com> wrote in message >> news:47D24246-0A0F-4592-BA23-91A29232F5CF@microsoft.com... >> >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. >> > >> >> >> David - thank you for your reply. I now know a little more about NTLM - your
comments were appreciated. I have checked out your suspicions, as follows: 1. AuthFlags is set to 2 (AuthBasic) for the entire site. I have checked that the directory security has been propogated down from the entire set settings to each of the two directories. The CGI reports AUTH_TYPE=Basic, as well as the username and password that I authenticated with. 2. I have tested on two completely separate networks - one internal in the US, and one in my home in the UK. I have even tested with no Internet connection, and all exhibit the same behaviour. I can be fairly confident that it is not a network setting or a proxy server. 3. I don't think I have installed any custom ISAPI filters - the only active ones are as follows: sspifilt, Compression, md5filt, pwsdata and ASP.NET_2.0.50727.42. Note that the problem only occurs if I open a new browser window, request an HTML file from one virtual directory, and then immediately execute a CGI from another virtual directory. Authentication happens when I request the HTML file. I have done some more digging. On running AuthMon and doing the steps in the preceding paragraph, I noticed that the first time I execute the CGI, I get two AuthMonRows and no HTTP_AUTHORIZATION variable. The same thing happens the second I time I execute the CGI. However, the third time I execute it, I get four AuthMonRows and this time I do get an HTTP_AUTHORIZATION variable. The fourth execution reverts to two AuthMonRows. Here is the relevant section of the AuthMon log: <AuthMonRow Number="100" tid="0x1b58" Date="03/27/2006 09:47:34.906" Name="OnNewRequest" Url="/Scripts/Test.exe" /> <AuthMonRow Number="101" tid="0x1b58" Date="03/27/2006 09:47:34.906" Name="OnNewRequest" Url="/Scripts/Test.exe" /> <AuthMonRow Number="102" tid="0x2b58" Date="03/27/2006 09:48:26.656" Name="OnNewRequest" Url="/Scripts/Test.exe" /> <AuthMonRow Number="103" tid="0x2b58" Date="03/27/2006 09:48:26.656" Name="OnNewRequest" Url="/Scripts/Test.exe" /> <AuthMonRow Number="104" tid="0x2b58" Date="03/27/2006 09:48:35.328" Name="OnNewRequest" Url="/Scripts/Test.exe" /> <AuthMonRow Number="105" tid="0x2b58" Date="03/27/2006 09:48:35.328" Name="OnNewRequest" Url="/Scripts/Test.exe" /> <AuthMonRow Number="106" tid="0x1b58" Date="03/27/2006 09:48:35.328" Name="OnNewRequest" Url="/Scripts/Test.exe" /> <AuthMonRow Number="107" tid="0x1b58" Date="03/27/2006 09:48:35.328" Name="OnNewRequest" Url="/Scripts/Test.exe" /> <AuthMonRow Number="108" tid="0x1b58" Date="03/27/2006 09:49:17.593" Name="OnNewRequest" Url="/Scripts/Test.exe" /> <AuthMonRow Number="109" tid="0x1b58" Date="03/27/2006 09:49:17.593" Name="OnNewRequest" Url="/Scripts/Test.exe" /> Hopefully, I will be testing another Web server today. Thanks, Andrew Show quoteHide quote "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" <AWillem***@discussions.microsoft.com> wrote in message > news:21DD82C6-74A2-4EEC-8D77-33C2159BA543@microsoft.com... > >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" <AWillem***@discussions.microsoft.com> wrote in message > >> news:47D24246-0A0F-4592-BA23-91A29232F5CF@microsoft.com... > >> >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. > >> > > >> > >> > >> > > > 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 Show quoteHide quote "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" <AWillem***@discussions.microsoft.com> wrote in message > news:21DD82C6-74A2-4EEC-8D77-33C2159BA543@microsoft.com... > >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" <AWillem***@discussions.microsoft.com> wrote in message > >> news:47D24246-0A0F-4592-BA23-91A29232F5CF@microsoft.com... > >> >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. > >> > > >> > >> > >> > > > 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. -- Show quoteHide quote//David IIS http://blogs.msdn.com/David.Wang This posting is provided "AS IS" with no warranties, and confers no rights. // "AWillemsen" <AWillem***@discussions.microsoft.com> wrote in message news:82B422B8-3D84-4989-AB80-9CC41CA8285B@microsoft.com... > 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" <AWillem***@discussions.microsoft.com> wrote in message >> news:21DD82C6-74A2-4EEC-8D77-33C2159BA543@microsoft.com... >> >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" <AWillem***@discussions.microsoft.com> wrote in message >> >> news:47D24246-0A0F-4592-BA23-91A29232F5CF@microsoft.com... >> >> >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. >> >> > >> >> >> >> >> >> >> >> >> 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 Show quoteHide quote "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" <AWillem***@discussions.microsoft.com> wrote in message > news:82B422B8-3D84-4989-AB80-9CC41CA8285B@microsoft.com... > > 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" <AWillem***@discussions.microsoft.com> wrote in message > >> news:21DD82C6-74A2-4EEC-8D77-33C2159BA543@microsoft.com... > >> >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" <AWillem***@discussions.microsoft.com> wrote in message > >> >> news:47D24246-0A0F-4592-BA23-91A29232F5CF@microsoft.com... > >> >> >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. > >> >> > > >> >> > >> >> > >> >> > >> > >> > >> > > > 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. -- Show quoteHide quote//David IIS http://blogs.msdn.com/David.Wang This posting is provided "AS IS" with no warranties, and confers no rights. // "AWillemsen" <AWillem***@discussions.microsoft.com> wrote in message news:42D3D5A7-899A-4AAF-B519-E07528227588@microsoft.com... > 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" <AWillem***@discussions.microsoft.com> wrote in message >> news:82B422B8-3D84-4989-AB80-9CC41CA8285B@microsoft.com... >> > 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" <AWillem***@discussions.microsoft.com> wrote in message >> >> news:21DD82C6-74A2-4EEC-8D77-33C2159BA543@microsoft.com... >> >> >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" <AWillem***@discussions.microsoft.com> wrote in >> >> >> message >> >> >> news:47D24246-0A0F-4592-BA23-91A29232F5CF@microsoft.com... >> >> >> >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. >> >> >> > >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> 
Other interesting topics
Is there a way of downloading .cer files like you would do with .doc or .MP3
DMZ and Domains IIS Manager on remote computer Multiple SSL certs on virtual servers - again Can't audit security events IIS Manager Closes Unexpectedly Understanding W3SVC1 logs Windows Authentication ¤ China ZhongZhan Aids Mei Mei ¤ China ZhongZhan Aids Mei Mei |
|||||||||||||||||||||||
