I tested the following configurations to prevent cookies from being deleted, but I'm still seeing the issue.

Open question: Do we want this to be implemented as CC 2.0?

In T361215#9962341, @Scardenasmolinar wrote:

Since this is in mediawiki-core and I noticed we only highlighted certain classes within the include directories, are these the only relevant classes or just the ones that we wanted to highlight as extra important?

These are most of the classes, but not all. I skipped some of the feed classes/files because that is used in other places besides Recent Changes. I also didn't look into the JS much.

Ok, thanks!

How do tickets get segmented into "recent changes" like here: https://phabricator.wikimedia.org/maniphest/query/fiZLq9u2qDQJ/#R is it based solely on directory structure?

I think these tickets have been triaged by people, which we will have to do (at least some of it) in the future. If people notice a spike in recent changes errors in logstash, a ticket will be added for us to look at.

Hope this helps!

Reviewed, and the investigation looks good to me. This is super helpful for me.

Waiting on

In T354154#9946650, @Novem_Linguae wrote:

cc patch author @Soda

Hello @Novem_Linguae, thank you for your work on this.

Should the link point to https://www.mediawiki.org/wiki/Skin_talk:Minerva_Neue instead of https://www.mediawiki.org/wiki/Skin:Minerva since it's the discussion link?

@jsn.sherman sounds good!

In T345104#9933028, @jsn.sherman wrote:

In T345104#9932816, @Kgraessle wrote:

In T345104#9932186, @jsn.sherman wrote:

@Kgraessle
Can you please share a WIP github PR with the ezproxy config changes you were testing to get these results? It's okay if some parts are commented out (with notes) if you tried a few different things.

In T345104#9931542, @Kgraessle wrote:

Adding login flow to corriere

Navigate to the Access collection button in staging for Corriere Della Serra archives and update the parameter URL to point to the login URL. Update the landing page to be our proxied URL.

<a href="https://wikipedialibrary.idm.oclc.org:9443/login?auth=staging&amp;url=https://www.corriere.it/account/login?landing=https://wikipedialibrary.idm.oclc.org:9443/login?auth=staging&amp;url=https://archivio.corriere.it/" class="btn btn-sm twl-btn access-apply-button" type="button" name="button" target="_blank" rel="noopener">
   Access collection
</a>

This will take you to a page that is proxied for the login flow. When I try to set the landing parameter to anything that isn't their domain (our proxy URL) then it won't let me sign in. The button is disabled and stops me from continuing through the flow.

I would expect that there is javascript validation happening to do that disable, which you would also need to capture with a rewrite rule to amend the allowed domains/hostnames. I'm surprised that the login url is being used here instead of the proxied endpoint( eg. https://archivio-corriere-it.wikipedialibrary.idm.oclc.org:9443)

If I add the landing parameter to be

<a href="https://wikipedialibrary.idm.oclc.org:9443/login?auth=staging&amp;url=https://www.corriere.it/account/login?landing=https://archivio.corriere.it/" class="btn btn-sm twl-btn access-apply-button" type="button" name="button" target="_blank" rel="noopener">
   Access collection
</a>

Then the flow continues to the site https://archivio.corriere.it/ without being proxied.

Unfortunately none of the config I updated was helpful, it's also hard to tell when the config goes out so it's been a bit tedious trying to test config without knowing if it's actually deployed or not.
I don't really have anything substantial to commit as a result.
I can tell you that my initial thoughts are that the image is being corrupted when the content provider is sending the data to the ezproxy server:

Because we know the images are being proxied correctly from the network tab request.

Initially, I thought these images were just designed to fill half of the height, but looking more closely at one of the impacted images, I'm not so sure now:

When I zoomed way in at the boundary, I saw a row of image data partially filled in.
My recollection is that it's always the same images that display this way? If so, we may need to ask them to check view those same images on their end just to verify that it is the proxy and not broken content.

Also,
I did a vimdiff on the two files
Left is proxied, right is unproxied.

In T345104#9932186, @jsn.sherman wrote:

@Kgraessle
Can you please share a WIP github PR with the ezproxy config changes you were testing to get these results? It's okay if some parts are commented out (with notes) if you tried a few different things.

In T345104#9931542, @Kgraessle wrote:

Adding login flow to corriere

Navigate to the Access collection button in staging for Corriere Della Serra archives and update the parameter URL to point to the login URL. Update the landing page to be our proxied URL.

<a href="https://wikipedialibrary.idm.oclc.org:9443/login?auth=staging&amp;url=https://www.corriere.it/account/login?landing=https://wikipedialibrary.idm.oclc.org:9443/login?auth=staging&amp;url=https://archivio.corriere.it/" class="btn btn-sm twl-btn access-apply-button" type="button" name="button" target="_blank" rel="noopener">
   Access collection
</a>

This will take you to a page that is proxied for the login flow. When I try to set the landing parameter to anything that isn't their domain (our proxy URL) then it won't let me sign in. The button is disabled and stops me from continuing through the flow.

I would expect that there is javascript validation happening to do that disable, which you would also need to capture with a rewrite rule to amend the allowed domains/hostnames. I'm surprised that the login url is being used here instead of the proxied endpoint( eg. https://archivio-corriere-it.wikipedialibrary.idm.oclc.org:9443)

If I add the landing parameter to be

<a href="https://wikipedialibrary.idm.oclc.org:9443/login?auth=staging&amp;url=https://www.corriere.it/account/login?landing=https://archivio.corriere.it/" class="btn btn-sm twl-btn access-apply-button" type="button" name="button" target="_blank" rel="noopener">
   Access collection
</a>

Then the flow continues to the site https://archivio.corriere.it/ without being proxied.

Adding login flow to corriere

In T367747#9928655, @Dzahn wrote:

Can I assume you mean "private data in Superset" and not just "Superset, dashboards without private data"? Because those are different requirements. You should already have Superset access, just excluding private data.

@odimitrijevic Could you approve this? Thanks!

Pulling this back into progress so I can check on CC compatibility.