[Webkit-unassigned] [Bug 149551] [SOUP] Slack.com is not working, new messages do not load due to WebSocket authentication failure issue

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=149551

--- Comment #32 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to Michael Catanzaro from comment #31)
> Comment on attachment 409698 [details]
> Patch
> 
> Well... surprise. Any idea why this isn't broken for Safari?

Yes, I guess safari doesn't use the new websockets yet. In WebKit websockets implementation the request already includes the right cookies. See WebSocketHandshake::clientHandshakeRequest(). That includes the cookies using the given cookieRequestHeaderFieldValue function that ends up in CookieJar::cookieRequestHeaderFieldValue(Document& document, const URL& url) that does the right thing for same site cookies.

> Looking for other suspicious cases,there are a lot of places where we call
> setFirstPartyForCookies but not addSameSiteInfoToRequestIfNeeded:
> WebKitWebSourceGStreamer.cpp, SWServer.cpp, XSLTProcessor.cpp,
> NetworkCacheSpeculativeLoadManager.cpp, NetworkDataTaskCocoa.mm,
> NetworkDataTaskSoup.cpp, and WebProcessPool.cpp. I wonder how many of these
> are similar bugs and how many are covered by FrameLoader?

I haven't looked in detail, but I think we are sometimes calling setFirstPartyForCookies more than once for the same request.

> I also wonder why cookie_is_valid_for_same_site_policy() isn't causing this
> problem? We probably still need to look closer at that....

cookie_is_valid_for_same_site_policy does the right thing when it receives a site for cookies, in this case it receives the document url instead of the websocket one, and the hosts match.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200926/73828116/attachment.htm>