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@xxxxxxxxxxxxxxxx
For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
--------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|