WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED DUPLICATE of
bug 230935
239944
Safari does not persist the Authorization header on redirect
https://bugs.webkit.org/show_bug.cgi?id=239944
Summary
Safari does not persist the Authorization header on redirect
lmx
Reported
2022-05-01 08:29:21 PDT
Sorry, my English is not good, the following content is generated by translation software. I describe the problem I have: In Safari, I send a request via fetch: /api/user/list?page=1&page_size=10 Because the path is wrong, the status code returned by the server is 301, and a new request path is given: /api/user/list/?page=1&page_size=10 After Safari receives 301, it automatically sends a new request, but does not bring the Authorization request header. My expectation is to bring the Authorization request header when redirecting, what should I do? Looking forward to your reply, thanks. Note: When redirecting, the Chrome browser will take the Authorization request with it. The full request log is below: First request(Has Authorization request header): Request GET /api/user/list?page=1&page_size=10 Authorization: Bearer xxxxxxxxxxxx Referer:
https://test.com/api/user/list?page=1&page_size=10
Accept: */* User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.2 Safari/605.1.15 Cache-Control: no-cache Pragma: no-cache X-OA-ID: 10004572 ------ Response to first request: Redirect Response 301 Moved Permanently Location: /api/user/list/?page=1&page_size=10 Date: Sun, 01 May 2022 09:29:24 GMT Referrer-Policy: same-origin ------ Redirects automatically sent by Safari(No Authorization header): Request GET /api/user/list/?page=1&page_size=10 HTTP/1.1 Accept: */* Pragma: no-cache Cookie: xxxxxxxxxxxx Referer:
https://test.com/api/user/list
Cache-Control: no-cache Host: test.com Accept-Language: en-US,en;q=0.9 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/15.2 Safari/605.1.15 Accept-Encoding: gzip, deflate, br Connection: keep-alive X-OA-ID: 10004572 ------ I found 2 similar questions on stackoverflow, but none were solved.
https://stackoverflow.com/questions/71311305/how-to-prevent-safari-from-dropping-the-authorization-header-when-following-a-sa
https://stackoverflow.com/questions/57974176/safari-does-not-persist-the-authorization-header-on-redirect
Attachments
Example
(2.92 KB, patch)
2022-05-16 08:04 PDT
,
youenn fablet
no flags
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
youenn fablet
Comment 1
2022-05-04 02:26:43 PDT
It seems to make sense to keep the authorization header for same origin redirections. It would be good to check where we are dropping the header (WebKit networking code or CFNetwork). See
https://github.com/whatwg/fetch/issues/944
for WhatWG fetch discussion.
Radar WebKit Bug Importer
Comment 2
2022-05-04 02:26:54 PDT
<
rdar://problem/92721299
>
youenn fablet
Comment 3
2022-05-16 08:04:43 PDT
Created
attachment 459426
[details]
Example
youenn fablet
Comment 4
2022-05-16 08:06:37 PDT
I uploaded an example which seems to show that the Authorisation header is being preserved on same origin redirections. @lmx, on which Safari version are you? Can you try Safari Tech Preview? Can you provide a repro case (public or privately at
youenn@apple.com
) or look at the provided example to see what is different?
lmx
Comment 5
2022-05-17 07:01:31 PDT
@youenn fablet Hello, I uploaded the code here.
https://github.com/mrlmx/safari-redirect-demo
You can also test through this online demo.
https://safari-redirect-demo.vercel.app
youenn fablet
Comment 6
2022-05-17 07:45:04 PDT
Testing in Safari Tech Preview on macOS Monterey, I get the list of users with
https://github.com/mrlmx/safari-redirect-demo
: lmx:18 foo:17 bar:16 @lmx, which version of Safari and iOS/macOS are you testing on?
lmx
Comment 7
2022-05-17 07:53:02 PDT
@youenn fablet Neither of my two Macs works properly. This is the corresponding version. --- macOS Monterey Version 12.1 (21C52) Safari Version 15.2 (17612.3.6.1.6) --- macOS Big Sur Version 11.3(20E232) Safari Version 14.1 (16611.1.21.161.3)
youenn fablet
Comment 8
2022-05-17 22:56:27 PDT
This is now fixed in latest Safari macOS 12.3 *** This bug has been marked as a duplicate of
bug 230935
***
lmx
Comment 9
2022-05-17 23:42:01 PDT
Thank you(In reply to youenn fablet from
comment #8
)
> This is now fixed in latest Safari macOS 12.3 > > *** This bug has been marked as a duplicate of
bug 230935
***
derben
Comment 10
2023-09-29 12:10:16 PDT
I’m still experiencing this issue on Safari for iOS on my IPhone SE 2020 running iOS 16.6.1. Shouldn’t this be fixed?
Alexey Proskuryakov
Comment 11
2023-09-29 12:34:13 PDT
Yes, it's supposed to have been fixed. Could you please file a new bug from scratch, with precise steps to reproduce and any additional information?
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug