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<humbed...@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-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
