Use WebPageProxy callbacks in case of authentication challenge received from Service Worker
Created attachment 377338 [details] Patch
Comment on attachment 377338 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=377338&action=review > Source/WebKit/UIProcess/Network/NetworkProcessProxy.cpp:325 > + store->client().didReceiveAuthenticationChallenge(WTFMove(authenticationChallenge)); I think we could remove this now. Is it still important to allow invalid TLS certs if there's no visible web page with the same origin? I think we could just add a requirement that if you want to use untrusted certs you have to have an open view.
(In reply to Alex Christensen from comment #2) > Comment on attachment 377338 [details] > Patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=377338&action=review > > > Source/WebKit/UIProcess/Network/NetworkProcessProxy.cpp:325 > > + store->client().didReceiveAuthenticationChallenge(WTFMove(authenticationChallenge)); > > I think we could remove this now. Is it still important to allow invalid > TLS certs if there's no visible web page with the same origin? I think we > could just add a requirement that if you want to use untrusted certs you > have to have an open view. Well, if the web page is not visible, user trust will never proceed although it would if the load was done for the web page. This is in particular the case if user trust was already granted by the application in the past and the web page proxy callback will not trigger any new prompt.
Comment on attachment 377338 [details] Patch Clearing flags on attachment: 377338 Committed r249277: <https://trac.webkit.org/changeset/249277>
All reviewed patches have been landed. Closing bug.
<rdar://problem/54839390>
Comment on attachment 377338 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=377338&action=review > Source/WebKit/NetworkProcess/NetworkResourceLoadParameters.cpp:89 > + if (sourceOrigin) > + encoder << *topOrigin; :( I'm fixing this.