You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@httpd.apache.org by ohaya <oh...@yahoo.com.INVALID> on 2021/10/04 01:04:45 UTC
[users@httpd] Browsers appear to be ignoring 401 responses with WWW-Authenticate
Hi,
We are hosting a page on one of our Apache (2.4.29). We use Oracle OAM webgate in this Apache to "protect" that page. When the webgate is installed into the Apache, they include a configuration file that has:
<LocationMatch "/*">
AuthType Oblix
require valid-user
</LocationMatch>
We have this page configured for BASIC authentication, i.e., a popup login page appears when an unauthenticated user attempts to access that URL.
If we access that page directly from a browser, we get a popup login page and then we enter username and password, and if that authenticates, the target page is sent to the browser.
However, we also have some users that access this page, "indirectly", i.e., they (for example) load a page into their browser that has some Javascript/XHR code, and then that code does a GET to retrieve the page.
The problem we are having is that in this latter scenario, the request just fails with a 401 not authorized, and the popup login page doesn't appear, so the user doesn't have an opportunity to enter their credentials.
I have been using various tools like Fiddler, Live headers, and also Wireshark to try to see what is going on... and I DO see what is happening, esp. with Wireshark, but I don't understand why the popups are not occurring.
Here is an example of a 401 response that I see in Wireshark:
Frame 157: 1322 bytes on wire (10576 bits), 1322 bytes captured (10576 bits) on interface \Device\NPF_{A65DD5E0-F324-4BF0-8115-255A8EC064BD}, id 0
Ethernet II, Src: PcsCompu_4d:6c:d9 (08:00:27:4d:6c:d9), Dst: PcsCompu_a8:ad:d1 (08:00:27:a8:ad:d1)
Internet Protocol Version 4, Src: 192.168.0.103, Dst: 192.168.0.10
Transmission Control Protocol, Src Port: 8080, Dst Port: 49786, Seq: 1, Ack: 444, Len: 1268
Hypertext Transfer Protocol
HTTP/1.1 401 Unauthorized\r\n
x-request-url: http://centos-apache3.whatever.com:7777/oamprotectedtarget/index.html\r\n
date: Mon, 04 Oct 2021 00:24:26 GMT\r\n
server: Apache/2.4.29 (Unix) OpenSSL/1.0.2k-fips\r\n
access-control-allow-origin: *\r\n
access-control-allow-credentials: true\r\n
access-control-allow-methods: GET, POST, OPTIONS\r\n
access-control-allow-headers: Origin, Content-Type, Accept\r\n
keep-alive: timeout=7, max=100\r\n
www-authenticate: Basic realm="ATNSCHEME-BasicSessionless"\r\n
content-length: 381\r\n
connection: close\r\n
content-type: text/html; charset=iso-8859-1\r\n
x-final-url: http://centos-apache3.whatever.com:7777/oamprotectedtarget/index.html\r\n
[truncated]access-control-expose-headers: date,server,access-control-allow-origin,access-control-allow-credentials,access-control-allow-methods,access-control-allow-headers,keep-alive,www-authenticate,content-length,connection,content-ty
\r\n
[HTTP response 1/1]
[Time since request: 0.009877000 seconds]
[Request in frame: 141]
[Request URI: http://192.168.0.103:8080/http://centos-apache3.whatever.com:7777/oamprotectedtarget/index.html]
File Data: 381 bytes
In this case, the Javascript page is loaded from a different machine than the one that is hosting the page, centos-apache1.whatever.com, and you can see, the 401/response has the CORS-response headers that should allow the browser to process the response?
In this type of scenario, is there some other restriction that would prevent or cause the browser to not popup the login window, even though the requests and responses appear to be all right?
Sorry about my description of this problem, but this scenario is complicated to explain :(...
Thanks in advance!!
Jim
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Browsers appear to be ignoring 401 responses with WWW-Authenticate
Posted by Eric Covener <co...@gmail.com>.
On Sun, Oct 3, 2021, 9:05 PM ohaya <oh...@yahoo.com.invalid> wrote:
> Hi,
>
> We are hosting a page on one of our Apache (2.4.29). We use Oracle OAM
> webgate in this Apache to "protect" that page. When the webgate is
> installed into the Apache, they include a configuration file that has:
>
> <LocationMatch "/*">
>
Does removing the * help?
Re: [users@httpd] Browsers appear to be ignoring 401 responses with
WWW-Authenticate
Posted by ohaya <oh...@yahoo.com.INVALID>.
Hi,
I just found this thread in SO:
https://stackoverflow.com/questions/18499465/cors-and-http-basic-auth
and specifically the response from "Brock Allen" on Aug 29, 2013:
"If you're requesting credentials then the server must respond with the specific origin in the Access-Control-Allow-Origin response header (and thus can't use the wildcard *). Of course it would then also need to respond with Access-Control-Allow-Credentials response header too."
And then I checked the 401 response that is going back to the browser in my Wireshark captures, and that 401 response does have:
access-control-allow-origin: *
So perhaps that (because of the *) may be preventing the browser from popping up the login window?
Thoughts?
Jim
On Sunday, October 3, 2021, 11:43:17 PM EDT, ohaya <oh...@yahoo.com> wrote:
Hi,
To be honest basic authentication is not a preference, but I'm looking into it because OAM supports what do you call sessionless basic authentication. And that is the only authentication method that OAM supports that doesn't require redirects, and previous work that I've done ready to problems because of the redirects and CORS, so I thought that the sessionless basic authentication might give me a better chance I'm actually getting this working ;)...
But then I am now running into this problem with the 401 responses not triggering the login.
I feel like there is some kind of rule that I am missing here, and I spent days now staring at wireshark captures everything looks like it just should work but it doesn't.
Thanks Jim
Sent from Yahoo Mail on Android
On Sun, Oct 3, 2021 at 9:12 PM, Daniel Gruno<hu...@apache.org> wrote: Slightly off-topic, but you might wanna check out
https://developer.mozilla.org/en-US/docs/Web/API/fetch#parameters
Standard modern behavior, AIUI, is to not do Basic Auth via JavaScript
fetches unless it's the same site, but this can be modified.
But I could be wrong :)
On 04/10/2021 03.04, ohaya wrote:
> Hi,
>
> We are hosting a page on one of our Apache (2.4.29). We use Oracle OAM webgate in this Apache to "protect" that page. When the webgate is installed into the Apache, they include a configuration file that has:
>
> <LocationMatch "/*">
> AuthType Oblix
> require valid-user
> </LocationMatch>
>
> We have this page configured for BASIC authentication, i.e., a popup login page appears when an unauthenticated user attempts to access that URL.
>
> If we access that page directly from a browser, we get a popup login page and then we enter username and password, and if that authenticates, the target page is sent to the browser.
>
> However, we also have some users that access this page, "indirectly", i.e., they (for example) load a page into their browser that has some Javascript/XHR code, and then that code does a GET to retrieve the page.
>
> The problem we are having is that in this latter scenario, the request just fails with a 401 not authorized, and the popup login page doesn't appear, so the user doesn't have an opportunity to enter their credentials.
>
> I have been using various tools like Fiddler, Live headers, and also Wireshark to try to see what is going on... and I DO see what is happening, esp. with Wireshark, but I don't understand why the popups are not occurring.
>
> Here is an example of a 401 response that I see in Wireshark:
>
> Frame 157: 1322 bytes on wire (10576 bits), 1322 bytes captured (10576 bits) on interface \Device\NPF_{A65DD5E0-F324-4BF0-8115-255A8EC064BD}, id 0
> Ethernet II, Src: PcsCompu_4d:6c:d9 (08:00:27:4d:6c:d9), Dst: PcsCompu_a8:ad:d1 (08:00:27:a8:ad:d1)
> Internet Protocol Version 4, Src: 192.168.0.103, Dst: 192.168.0.10
> Transmission Control Protocol, Src Port: 8080, Dst Port: 49786, Seq: 1, Ack: 444, Len: 1268
> Hypertext Transfer Protocol
> HTTP/1.1 401 Unauthorized\r\n
> x-request-url: http://centos-apache3.whatever.com:7777/oamprotectedtarget/index.html\r\n
> date: Mon, 04 Oct 2021 00:24:26 GMT\r\n
> server: Apache/2.4.29 (Unix) OpenSSL/1.0.2k-fips\r\n
> access-control-allow-origin: *\r\n
> access-control-allow-credentials: true\r\n
> access-control-allow-methods: GET, POST, OPTIONS\r\n
> access-control-allow-headers: Origin, Content-Type, Accept\r\n
> keep-alive: timeout=7, max=100\r\n
> www-authenticate: Basic realm="ATNSCHEME-BasicSessionless"\r\n
> content-length: 381\r\n
> connection: close\r\n
> content-type: text/html; charset=iso-8859-1\r\n
> x-final-url: http://centos-apache3.whatever.com:7777/oamprotectedtarget/index.html\r\n
> [truncated]access-control-expose-headers: date,server,access-control-allow-origin,access-control-allow-credentials,access-control-allow-methods,access-control-allow-headers,keep-alive,www-authenticate,content-length,connection,content-ty
> \r\n
> [HTTP response 1/1]
> [Time since request: 0.009877000 seconds]
> [Request in frame: 141]
> [Request URI: http://192.168.0.103:8080/http://centos-apache3.whatever.com:7777/oamprotectedtarget/index.html]
> File Data: 381 bytes
>
> In this case, the Javascript page is loaded from a different machine than the one that is hosting the page, centos-apache1.whatever.com, and you can see, the 401/response has the CORS-response headers that should allow the browser to process the response?
>
> In this type of scenario, is there some other restriction that would prevent or cause the browser to not popup the login window, even though the requests and responses appear to be all right?
>
> Sorry about my description of this problem, but this scenario is complicated to explain :(...
>
> Thanks in advance!!
>
> Jim
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Browsers appear to be ignoring 401 responses with WWW-Authenticate
Posted by Daniel Ferradal <df...@apache.org>.
Another side note:
OAM, redirects and CORS...
Another victim of the "samesite" debacle?
Oracle released a "fix" so oam and webgate would specify "samesite"
cookie parameter and/or to specify whatever you wanted in it... if
that's your case.
Cheers
El lun, 4 oct 2021 a las 5:43, ohaya (<oh...@yahoo.com.invalid>) escribió:
>
> Hi,
>
> To be honest basic authentication is not a preference, but I'm looking into it because OAM supports what do you call sessionless basic authentication. And that is the only authentication method that OAM supports that doesn't require redirects, and previous work that I've done ready to problems because of the redirects and CORS, so I thought that the sessionless basic authentication might give me a better chance I'm actually getting this working ;)...
>
> But then I am now running into this problem with the 401 responses not triggering the login.
>
> I feel like there is some kind of rule that I am missing here, and I spent days now staring at wireshark captures everything looks like it just should work but it doesn't.
>
> Thanks
> Jim
>
>
>
> Sent from Yahoo Mail on Android
>
> On Sun, Oct 3, 2021 at 9:12 PM, Daniel Gruno
> <hu...@apache.org> wrote:
> Slightly off-topic, but you might wanna check out
> https://developer.mozilla.org/en-US/docs/Web/API/fetch#parameters
> Standard modern behavior, AIUI, is to not do Basic Auth via JavaScript
> fetches unless it's the same site, but this can be modified.
>
> But I could be wrong :)
>
> On 04/10/2021 03.04, ohaya wrote:
> > Hi,
> >
> > We are hosting a page on one of our Apache (2.4.29). We use Oracle OAM webgate in this Apache to "protect" that page. When the webgate is installed into the Apache, they include a configuration file that has:
> >
> > <LocationMatch "/*">
> > AuthType Oblix
> > require valid-user
> > </LocationMatch>
> >
> > We have this page configured for BASIC authentication, i.e., a popup login page appears when an unauthenticated user attempts to access that URL.
> >
> > If we access that page directly from a browser, we get a popup login page and then we enter username and password, and if that authenticates, the target page is sent to the browser.
> >
> > However, we also have some users that access this page, "indirectly", i.e., they (for example) load a page into their browser that has some Javascript/XHR code, and then that code does a GET to retrieve the page.
> >
> > The problem we are having is that in this latter scenario, the request just fails with a 401 not authorized, and the popup login page doesn't appear, so the user doesn't have an opportunity to enter their credentials.
> >
> > I have been using various tools like Fiddler, Live headers, and also Wireshark to try to see what is going on... and I DO see what is happening, esp. with Wireshark, but I don't understand why the popups are not occurring.
> >
> > Here is an example of a 401 response that I see in Wireshark:
> >
> > Frame 157: 1322 bytes on wire (10576 bits), 1322 bytes captured (10576 bits) on interface \Device\NPF_{A65DD5E0-F324-4BF0-8115-255A8EC064BD}, id 0
> > Ethernet II, Src: PcsCompu_4d:6c:d9 (08:00:27:4d:6c:d9), Dst: PcsCompu_a8:ad:d1 (08:00:27:a8:ad:d1)
> > Internet Protocol Version 4, Src: 192.168.0.103, Dst: 192.168.0.10
> > Transmission Control Protocol, Src Port: 8080, Dst Port: 49786, Seq: 1, Ack: 444, Len: 1268
> > Hypertext Transfer Protocol
> > HTTP/1.1 401 Unauthorized\r\n
> > x-request-url: http://centos-apache3.whatever.com:7777/oamprotectedtarget/index.html\r\n
> > date: Mon, 04 Oct 2021 00:24:26 GMT\r\n
> > server: Apache/2.4.29 (Unix) OpenSSL/1.0.2k-fips\r\n
> > access-control-allow-origin: *\r\n
> > access-control-allow-credentials: true\r\n
> > access-control-allow-methods: GET, POST, OPTIONS\r\n
> > access-control-allow-headers: Origin, Content-Type, Accept\r\n
> > keep-alive: timeout=7, max=100\r\n
> > www-authenticate: Basic realm="ATNSCHEME-BasicSessionless"\r\n
> > content-length: 381\r\n
> > connection: close\r\n
> > content-type: text/html; charset=iso-8859-1\r\n
> > x-final-url: http://centos-apache3.whatever.com:7777/oamprotectedtarget/index.html\r\n
> > [truncated]access-control-expose-headers: date,server,access-control-allow-origin,access-control-allow-credentials,access-control-allow-methods,access-control-allow-headers,keep-alive,www-authenticate,content-length,connection,content-ty
> > \r\n
> > [HTTP response 1/1]
> > [Time since request: 0.009877000 seconds]
> > [Request in frame: 141]
> > [Request URI: http://192.168.0.103:8080/http://centos-apache3.whatever.com:7777/oamprotectedtarget/index.html]
> > File Data: 381 bytes
> >
> > In this case, the Javascript page is loaded from a different machine than the one that is hosting the page, centos-apache1.whatever.com, and you can see, the 401/response has the CORS-response headers that should allow the browser to process the response?
> >
> > In this type of scenario, is there some other restriction that would prevent or cause the browser to not popup the login window, even though the requests and responses appear to be all right?
> >
> > Sorry about my description of this problem, but this scenario is complicated to explain :(...
> >
> > Thanks in advance!!
> >
> > Jim
>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> > For additional commands, e-mail: users-help@httpd.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
>
--
Daniel Ferradal
HTTPD Project
#httpd help at Libera.Chat
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Browsers appear to be ignoring 401 responses with
WWW-Authenticate
Posted by ohaya <oh...@yahoo.com.INVALID>.
Hi,
To be honest basic authentication is not a preference, but I'm looking into it because OAM supports what do you call sessionless basic authentication. And that is the only authentication method that OAM supports that doesn't require redirects, and previous work that I've done ready to problems because of the redirects and CORS, so I thought that the sessionless basic authentication might give me a better chance I'm actually getting this working ;)...
But then I am now running into this problem with the 401 responses not triggering the login.
I feel like there is some kind of rule that I am missing here, and I spent days now staring at wireshark captures everything looks like it just should work but it doesn't.
Thanks Jim
Sent from Yahoo Mail on Android
On Sun, Oct 3, 2021 at 9:12 PM, Daniel Gruno<hu...@apache.org> wrote: Slightly off-topic, but you might wanna check out
https://developer.mozilla.org/en-US/docs/Web/API/fetch#parameters
Standard modern behavior, AIUI, is to not do Basic Auth via JavaScript
fetches unless it's the same site, but this can be modified.
But I could be wrong :)
On 04/10/2021 03.04, ohaya wrote:
> Hi,
>
> We are hosting a page on one of our Apache (2.4.29). We use Oracle OAM webgate in this Apache to "protect" that page. When the webgate is installed into the Apache, they include a configuration file that has:
>
> <LocationMatch "/*">
> AuthType Oblix
> require valid-user
> </LocationMatch>
>
> We have this page configured for BASIC authentication, i.e., a popup login page appears when an unauthenticated user attempts to access that URL.
>
> If we access that page directly from a browser, we get a popup login page and then we enter username and password, and if that authenticates, the target page is sent to the browser.
>
> However, we also have some users that access this page, "indirectly", i.e., they (for example) load a page into their browser that has some Javascript/XHR code, and then that code does a GET to retrieve the page.
>
> The problem we are having is that in this latter scenario, the request just fails with a 401 not authorized, and the popup login page doesn't appear, so the user doesn't have an opportunity to enter their credentials.
>
> I have been using various tools like Fiddler, Live headers, and also Wireshark to try to see what is going on... and I DO see what is happening, esp. with Wireshark, but I don't understand why the popups are not occurring.
>
> Here is an example of a 401 response that I see in Wireshark:
>
> Frame 157: 1322 bytes on wire (10576 bits), 1322 bytes captured (10576 bits) on interface \Device\NPF_{A65DD5E0-F324-4BF0-8115-255A8EC064BD}, id 0
> Ethernet II, Src: PcsCompu_4d:6c:d9 (08:00:27:4d:6c:d9), Dst: PcsCompu_a8:ad:d1 (08:00:27:a8:ad:d1)
> Internet Protocol Version 4, Src: 192.168.0.103, Dst: 192.168.0.10
> Transmission Control Protocol, Src Port: 8080, Dst Port: 49786, Seq: 1, Ack: 444, Len: 1268
> Hypertext Transfer Protocol
> HTTP/1.1 401 Unauthorized\r\n
> x-request-url: http://centos-apache3.whatever.com:7777/oamprotectedtarget/index.html\r\n
> date: Mon, 04 Oct 2021 00:24:26 GMT\r\n
> server: Apache/2.4.29 (Unix) OpenSSL/1.0.2k-fips\r\n
> access-control-allow-origin: *\r\n
> access-control-allow-credentials: true\r\n
> access-control-allow-methods: GET, POST, OPTIONS\r\n
> access-control-allow-headers: Origin, Content-Type, Accept\r\n
> keep-alive: timeout=7, max=100\r\n
> www-authenticate: Basic realm="ATNSCHEME-BasicSessionless"\r\n
> content-length: 381\r\n
> connection: close\r\n
> content-type: text/html; charset=iso-8859-1\r\n
> x-final-url: http://centos-apache3.whatever.com:7777/oamprotectedtarget/index.html\r\n
> [truncated]access-control-expose-headers: date,server,access-control-allow-origin,access-control-allow-credentials,access-control-allow-methods,access-control-allow-headers,keep-alive,www-authenticate,content-length,connection,content-ty
> \r\n
> [HTTP response 1/1]
> [Time since request: 0.009877000 seconds]
> [Request in frame: 141]
> [Request URI: http://192.168.0.103:8080/http://centos-apache3.whatever.com:7777/oamprotectedtarget/index.html]
> File Data: 381 bytes
>
> In this case, the Javascript page is loaded from a different machine than the one that is hosting the page, centos-apache1.whatever.com, and you can see, the 401/response has the CORS-response headers that should allow the browser to process the response?
>
> In this type of scenario, is there some other restriction that would prevent or cause the browser to not popup the login window, even though the requests and responses appear to be all right?
>
> Sorry about my description of this problem, but this scenario is complicated to explain :(...
>
> Thanks in advance!!
>
> Jim
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org
Re: [users@httpd] Browsers appear to be ignoring 401 responses with
WWW-Authenticate
Posted by Daniel Gruno <hu...@apache.org>.
Slightly off-topic, but you might wanna check out
https://developer.mozilla.org/en-US/docs/Web/API/fetch#parameters
Standard modern behavior, AIUI, is to not do Basic Auth via JavaScript
fetches unless it's the same site, but this can be modified.
But I could be wrong :)
On 04/10/2021 03.04, ohaya wrote:
> Hi,
>
> We are hosting a page on one of our Apache (2.4.29). We use Oracle OAM webgate in this Apache to "protect" that page. When the webgate is installed into the Apache, they include a configuration file that has:
>
> <LocationMatch "/*">
> AuthType Oblix
> require valid-user
> </LocationMatch>
>
> We have this page configured for BASIC authentication, i.e., a popup login page appears when an unauthenticated user attempts to access that URL.
>
> If we access that page directly from a browser, we get a popup login page and then we enter username and password, and if that authenticates, the target page is sent to the browser.
>
> However, we also have some users that access this page, "indirectly", i.e., they (for example) load a page into their browser that has some Javascript/XHR code, and then that code does a GET to retrieve the page.
>
> The problem we are having is that in this latter scenario, the request just fails with a 401 not authorized, and the popup login page doesn't appear, so the user doesn't have an opportunity to enter their credentials.
>
> I have been using various tools like Fiddler, Live headers, and also Wireshark to try to see what is going on... and I DO see what is happening, esp. with Wireshark, but I don't understand why the popups are not occurring.
>
> Here is an example of a 401 response that I see in Wireshark:
>
> Frame 157: 1322 bytes on wire (10576 bits), 1322 bytes captured (10576 bits) on interface \Device\NPF_{A65DD5E0-F324-4BF0-8115-255A8EC064BD}, id 0
> Ethernet II, Src: PcsCompu_4d:6c:d9 (08:00:27:4d:6c:d9), Dst: PcsCompu_a8:ad:d1 (08:00:27:a8:ad:d1)
> Internet Protocol Version 4, Src: 192.168.0.103, Dst: 192.168.0.10
> Transmission Control Protocol, Src Port: 8080, Dst Port: 49786, Seq: 1, Ack: 444, Len: 1268
> Hypertext Transfer Protocol
> HTTP/1.1 401 Unauthorized\r\n
> x-request-url: http://centos-apache3.whatever.com:7777/oamprotectedtarget/index.html\r\n
> date: Mon, 04 Oct 2021 00:24:26 GMT\r\n
> server: Apache/2.4.29 (Unix) OpenSSL/1.0.2k-fips\r\n
> access-control-allow-origin: *\r\n
> access-control-allow-credentials: true\r\n
> access-control-allow-methods: GET, POST, OPTIONS\r\n
> access-control-allow-headers: Origin, Content-Type, Accept\r\n
> keep-alive: timeout=7, max=100\r\n
> www-authenticate: Basic realm="ATNSCHEME-BasicSessionless"\r\n
> content-length: 381\r\n
> connection: close\r\n
> content-type: text/html; charset=iso-8859-1\r\n
> x-final-url: http://centos-apache3.whatever.com:7777/oamprotectedtarget/index.html\r\n
> [truncated]access-control-expose-headers: date,server,access-control-allow-origin,access-control-allow-credentials,access-control-allow-methods,access-control-allow-headers,keep-alive,www-authenticate,content-length,connection,content-ty
> \r\n
> [HTTP response 1/1]
> [Time since request: 0.009877000 seconds]
> [Request in frame: 141]
> [Request URI: http://192.168.0.103:8080/http://centos-apache3.whatever.com:7777/oamprotectedtarget/index.html]
> File Data: 381 bytes
>
> In this case, the Javascript page is loaded from a different machine than the one that is hosting the page, centos-apache1.whatever.com, and you can see, the 401/response has the CORS-response headers that should allow the browser to process the response?
>
> In this type of scenario, is there some other restriction that would prevent or cause the browser to not popup the login window, even though the requests and responses appear to be all right?
>
> Sorry about my description of this problem, but this scenario is complicated to explain :(...
>
> Thanks in advance!!
>
> Jim
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
> For additional commands, e-mail: users-help@httpd.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@httpd.apache.org
For additional commands, e-mail: users-help@httpd.apache.org