1

xhr.open(...) with username and password works only when the script is at the same domain as the URI. This appears to be due to the so-called same origin policy. As one would note from this answer here on StackOverflow, one can send an explicit Authorization header with the xhr request, thus bypassing the same origin policy.

The question is why do we then have this same origin policy that can, with little effort, be bypassed?

Thanks in advance!

pengu1n
  • 471
  • 6
  • 15
  • 1
    a little thing called `CORS` would stand in your way, so you're not really bypassing anything – Jaromanda X Aug 08 '17 at 06:18
  • Why would then a browser refuse to send XHR credentials to the server that is on a different domain? It could simply let them through - since they can be sent through the Authorization header anyway. – pengu1n Aug 08 '17 at 06:30
  • setting user/password in `open` (not `send` as your question implies) doesn't add an Authorization header. Given a domain `http://example.com/` `.open('GET', '/path/resource.ext', false, 'user', 'password')` would result in the request `http://user:password@example.com/path/resource.ext` – Jaromanda X Aug 08 '17 at 06:48
  • 1
    Thanks! Yet, the browser refuses to send the request implied by .open('GET', '/path/resource.ext', false, 'user', 'password') but one can still do .open('GET', '/path/resource.ext', false) with .setRequestHeader("Authorization", "blahblah"). Why does the browser refuse the former? – pengu1n Aug 08 '17 at 07:00
  • Did you resolve it? – JustAnotherDeveloper Nov 23 '21 at 16:09
  • No, I didn't find an answer. – pengu1n Feb 27 '22 at 19:32

0 Answers0