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 > <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 > > -- Daniel Ferradal HTTPD Project #httpd help at Libera.Chat --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
