The PDF export is passing the cookies to the headless Chrome. Authentication cookies are IP-bound, so they are re-encoded using the IP address of the headless Chrome. This was working fine before XWIKI-22694 because the requests made by the headless Chrome were seen by XWiki as made by the headless Chrome, so the authentication cookies had to be re-encoded using the IP of the headless Chrome. Starting with XWIKI-22694, the headless Chrome becomes a proxy that forwards the user's request (to export to PDF) to XWiki, and "filters" the response, by replacing the returned HTML content with the generated PDF file. The "Forwarded" HTTP header makes XWiki think that the client making the request is the user's browser, so cookies don't have to be re-encoded. If we re-encoded them we break the authentication.
Unfortunately we can't remove completely the cookie filtering, because in some strict environments, the number of proxies between the user's browser and the server is known and verified. In this case, adding a new proxy (the headless Chrome) might change the perceived client, so we'd still have to re-encoded the cookies. To satisfy both cases, we're using this approach:
we first make a request through headless Chrome without the Forwarded HTTP header in order to get its IP address
then we set the Forwarded HTTP header, making the headless Chrome a proxy
we make another request through headless Chrome to get the IP address
if the added proxy is accepted, we'll get the IP address of the user's browser
if the added proxy is not accepted, we'll get the IP address of the headless Chrome
in both cases the returned IP address is the one that needs to be used to re-encoded the cookies; of course, if we get the user's browser IP address the cookies don't need to be re-encoded, but the cost is marginal
finally we load the print preview URL in Chrome, passing the filtered cookies
This message was sent by Atlassian Jira (v9.3.0#930000-sha1:287aeb6)
If image attachments aren't displayed, see this article.
