2

When using the "Samsung internet" browser on an Android device, it fails to do Ajax (some work) requests. After some debugging I saw that the browser only sends the options request (which succeeds) but does not send the corresponding post request afterwards.

You can try yourself by visiting my Dev site, select ok on the confirm prompt, click on login and try to login with random data

https://dev.gameplaylan.de

Jan Jaap
  • 41
  • 1
  • 5
  • 1
    Hi there, my bet is you forgot to paste your link ;) – Ggg Aug 25 '18 at 19:29
  • Actually it's been there, but the https was all capital and so seems to have some kinda replacement logic which looks after that ‍♂️ well, now it's there – Jan Jaap Aug 25 '18 at 20:29
  • Just on a side note: Don't ever use `Access-Control-Allow-Origin: *` in any production code. It's an awful security hole. And if you are using cookies, it won't work with CORS, you would then need a reverse proxy. – ssc-hrep3 Aug 25 '18 at 20:33
  • @ssc-hrep3 you don't have a choice on webview though – Eric Aug 25 '18 at 20:40
  • Thanks for the side node will change it soon ^^ – Jan Jaap Aug 26 '18 at 00:13
  • The cookie problem is not a problem for me, the application does not need any. – Jan Jaap Aug 26 '18 at 00:13
  • But this still does not explain the weird behaviour of the Samsung browser... All other browsers work fine... – Jan Jaap Aug 26 '18 at 01:29
  • Side note on that side note — see the answer at https://stackoverflow.com/questions/43154170/is-it-safe-to-enable-cors-to-for-a-public-and-readonly-webservice/43154277#43154277 – sideshowbarker Aug 26 '18 at 04:06
  • 1
    Instead of using the `*` wildcard for the Access-Control-Allow-Headers and Access-Control-Allow-Methods response headers, try having the server instead send a list of the explicit method names and header names your frontend sends/needs. Because my guess is that the Samsung browser probably doesn’t recognize the `*` wildcard for the Access-Control-Allow-Headers and Access-Control-Allow-Methods response headers. So the preflight isn’t actually succeeding in the Samsung browser — it’s instead failing because the browser isn’t seeing the explicit header names and method names it expects. – sideshowbarker Aug 26 '18 at 04:53
  • Try opening http://web-platform-tests.live/fetch/api/cors/cors-preflight-star.any.html in the Samsung browser. If you don’t see *10 pass* and instead see any failures, then that’s an indication it’s not handling the `*` wildcard for Access-Control-Allow-Headers and Access-Control-Allow-Methods as expected in at least some cases. – sideshowbarker Aug 26 '18 at 05:32
  • That's been it! 2 of 10 tests fail (the wildcard tests). – Jan Jaap Aug 28 '18 at 05:49

1 Answers1

2

As mentioned in the comments, it seems like the Samsung internet browser doesn't handle wildcard access-control headers.

So I need to switch to an explicit list...

Jan Jaap
  • 41
  • 1
  • 5