Bug 234809

Summary: Make sure secure websocket connections in service workers can trigger authentication challenge callbacks
Product: WebKit Reporter: youenn fablet <youennf>
Component: Service WorkersAssignee: youenn fablet <youennf>
Status: RESOLVED FIXED    
Severity: Normal CC: achristensen, cdumez, esprehn+autocc, ews-watchlist, jenner, kangil.han, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch
none
Patch
none
Patch
none
Patch
none
Patch for landing ews-feeder: commit-queue-

youenn fablet
Reported 2022-01-03 02:42:12 PST
Make sure secure websocket connections in service workers can trigger authentication challenge callbacks
Attachments
Patch (21.96 KB, patch)
2022-01-03 02:51 PST, youenn fablet
no flags
Patch (26.53 KB, patch)
2022-01-03 08:44 PST, youenn fablet
no flags
Patch (27.18 KB, patch)
2022-01-03 11:12 PST, youenn fablet
no flags
Patch (45.96 KB, patch)
2022-01-04 01:01 PST, youenn fablet
no flags
Patch (46.16 KB, patch)
2022-01-04 04:18 PST, youenn fablet
no flags
Patch for landing (29.05 KB, patch)
2022-01-05 01:06 PST, youenn fablet
ews-feeder: commit-queue-
youenn fablet
Comment 1 2022-01-03 02:42:27 PST
youenn fablet
Comment 2 2022-01-03 02:51:36 PST
youenn fablet
Comment 3 2022-01-03 08:44:02 PST
youenn fablet
Comment 4 2022-01-03 11:12:51 PST
youenn fablet
Comment 5 2022-01-04 01:01:32 PST
youenn fablet
Comment 6 2022-01-04 04:18:17 PST
Chris Dumez
Comment 7 2022-01-04 09:21:13 PST
Comment on attachment 448250 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=448250&action=review r=me > Source/WebKit/NetworkProcess/cocoa/WebSocketTaskCocoa.h:73 > + const std::optional<WebCore::SecurityOriginData>& topOrigin() const { return m_topOrigin; } SecurityOriginData has an "empty" state so we could use a SecurityOriginData as data members (instead of a std::optional<>) and have the call sites check SecurityOriginData::isEmpty(). > Source/WebKit/NetworkProcess/cocoa/WebSocketTaskCocoa.mm:51 > + if (clientOrigin.topOrigin == clientOrigin.clientOrigin) This could use a comment to explain why we only initialize m_topOrigin if topOrigin is the same as clientOrigin. > Source/WebKit/WebProcess/Network/WebSocketChannel.cpp:121 > + MessageSender::send(Messages::NetworkConnectionToWebProcess::CreateSocketChannel { *request, protocol, m_identifier, m_webPageProxyID, ClientOrigin { m_document->topOrigin().data(), m_document->securityOrigin().data() } }); I bet we have this logic in several places and it may be worth having a getter on Document that returns a ClientOrigin at this point.
Alex Christensen
Comment 8 2022-01-04 09:58:45 PST
Comment on attachment 448250 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=448250&action=review > LayoutTests/platform/mac-bigsur-wk2/http/tests/workers/service/serviceworker-websocket.https-expected.txt:3 > +PASS Open a WebSocket in service worker These files are identical to the platform independent version and unnecessary.
youenn fablet
Comment 9 2022-01-04 10:16:19 PST
(In reply to Alex Christensen from comment #8) > Comment on attachment 448250 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=448250&action=review > > > LayoutTests/platform/mac-bigsur-wk2/http/tests/workers/service/serviceworker-websocket.https-expected.txt:3 > > +PASS Open a WebSocket in service worker > > These files are identical to the platform independent version and > unnecessary. Not really, they are missing the canAuthenticateAgainstProtectionSpace line. I guess we could reverse the files but in the future, all cocoa ports will probably be aligned with the updated test expectation.
Alex Christensen
Comment 10 2022-01-04 10:17:16 PST
Comment on attachment 448250 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=448250&action=review >>> LayoutTests/platform/mac-bigsur-wk2/http/tests/workers/service/serviceworker-websocket.https-expected.txt:3 >>> +PASS Open a WebSocket in service worker >> >> These files are identical to the platform independent version and unnecessary. > > Not really, they are missing the canAuthenticateAgainstProtectionSpace line. > I guess we could reverse the files but in the future, all cocoa ports will probably be aligned with the updated test expectation. oh, of course. I was looking at it wrong. This is fine.
youenn fablet
Comment 11 2022-01-05 01:06:43 PST
Created attachment 448365 [details] Patch for landing
EWS
Comment 12 2022-01-05 02:36:56 PST
Committed r287611 (245738@main): <https://commits.webkit.org/245738@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 448365 [details].
youenn fablet
Comment 13 2022-01-05 02:58:44 PST
Took it all. (In reply to Chris Dumez from comment #7) > Comment on attachment 448250 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=448250&action=review > > r=me > > > Source/WebKit/NetworkProcess/cocoa/WebSocketTaskCocoa.h:73 > > + const std::optional<WebCore::SecurityOriginData>& topOrigin() const { return m_topOrigin; } > > SecurityOriginData has an "empty" state so we could use a SecurityOriginData > as data members (instead of a std::optional<>) and have the call sites check > SecurityOriginData::isEmpty(). > > > Source/WebKit/NetworkProcess/cocoa/WebSocketTaskCocoa.mm:51 > > + if (clientOrigin.topOrigin == clientOrigin.clientOrigin) > > This could use a comment to explain why we only initialize m_topOrigin if > topOrigin is the same as clientOrigin. > > > Source/WebKit/WebProcess/Network/WebSocketChannel.cpp:121 > > + MessageSender::send(Messages::NetworkConnectionToWebProcess::CreateSocketChannel { *request, protocol, m_identifier, m_webPageProxyID, ClientOrigin { m_document->topOrigin().data(), m_document->securityOrigin().data() } }); > > I bet we have this logic in several places and it may be worth having a > getter on Document that returns a ClientOrigin at this point.
youenn fablet
Comment 14 2022-01-05 08:16:35 PST
*** Bug 233665 has been marked as a duplicate of this bug. ***
Note You need to log in before you can comment on or make changes to this bug.