From @jsn.sherman when testing PNAS:

on this particular example, we start out fine until we request:
https://www-pnas-org.wikipedialibrary.idm.oclc.org/action/oidcStart?redirectUri=%2F

we get the response:

HTTP/1.1 302 
Date: Wed, 09 Oct 2024 13:28:13 GMT
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=15552000
X-Frame-Options: SAMEORIGIN
Referrer-Policy: no-referrer-when-downgrade
Cache-Control: no-cache
X-Webstats-RespID: 90e149a481f4231e7be1349c05d8ee77
Location: https://pnas.scienceconnect.io/api/oauth/authorize?ui_locales=en&scope=affiliations+login_method+merged_users+openid+settings&response_type=code&redirect_uri=https%3A%2F%2Fwww.pnas.org%2Faction%2FoidcCallback%3FidpCode%3Dconnect&state=u-qAaqxY-OnQGa8teOCGDcSG_L6KqGONOp6wQKLVzdE&prompt=none&nonce=7KQ2AI1HRA3pmeEwvn5pU2nN8jPj0VKkTmbHqmE6toA%3D&client_id=pnas
CF-Cache-Status: DYNAMIC
Server: cloudflare
CF-RAY: 8cfeb66afa5d0276-ORD
Content-Length: 0
Connection: close

which is sending us out of the proxy by redirecting us to
https://pnas.scienceconnect.io/api/oauth/authorize?ui_locales=en&scope=affiliations+login_method+merged_users+openid+settings&response_type=code&redirect_uri=https%3A%2F%2Fwww.pnas.org%2Faction%2FoidcCallback%3FidpCode%3Dconnect&state=u-qAaqxY-OnQGa8teOCGDcSG_L6KqGONOp6wQKLVzdE&prompt=none&nonce=7KQ2AI1HRA3pmeEwvn5pU2nN8jPj0VKkTmbHqmE6toA%3D&client_id=pnas

this appears to be a cloudflare-managed oauth endpoint and it is not in the stanza for this resource
https://help.oclc.org/Library_Management/EZproxy/EZproxy_database_stanzas/Database_stanzas_P/Proceedings_of_the_National_Academy_of_Sciences

I've noticed that the Numérique Premium resource will sometimes have a similar issue with the skip thing in the URL. Unsure if it's the exact same issue. However, this one sometimes works. It's massively finicky, and even when in the proxy it will sometimes cease to work when you're accessing a resource, or randomly do the skip thing and push you out of the proxy. Unsure what drives it.

We spoke to our contact at PNAS last week and they said this is a known issue, something to do with the connection between Atypon Connect and Cloudflare. They asked us to send over additional information so they could look into this - it seems like it's solvable on the publisher's end.

Looks like this is now affecting Wiley too.

Might be related to the Wiley issue where it tries to redirect the TWL URL when it is on an open-access article?

The hosted PNAS entry has been updated to include the .scienceconnect.io host
https://help.oclc.org/Library_Management/EZproxy/EZproxy_database_stanzas/Database_stanzas_P/Proceedings_of_the_National_Academy_of_Sciences
but we're still seeing the issue.

It appears that this behavior is part of a publisher-side ezproxy specific flow for auth. I think the skip=true probably refers to skipping a cloudflare-hosted oauth login flow.
Here's an example wiley page that shows this in action:
unproxied:
https://onlinelibrary.wiley.com/action/showIdentities:
proxied:
https://onlinelibrary-wiley-com.wikipedialibrary.idm.oclc.org/action/showIdentities

I'm going to test a workaround but after researching this, I'm doubtful it will work. I'll post an update today.

I saw the wiley behavior change while testing; I believe it was after I restarted our proxy. There was a recent update to the hosted wiley config. Could someone please confirm if they are being redirected out of the proxy with a ?skip=true URL parameter?

I haven't made any changes to wiley yet, but I have put some fixes in place for T322974: PNAS resources are unavailable, T375781: Sabinet WPL resource does not work, and T363316: World Scientific access has expired

To allow cookies to pass through the scienceconnect.io oauth flow, we need to proxy the appropriate fqdn and allow anonymous access at the start of it. PNAS partially implemented the fix, but didn't have the anonymous url configured in the hosted ezproxy stanza.

AnonymousURL +https://<partner subdomain>.scienceconnect.io/api/oauth/*
<partner stanza start>
HJ <partner subdomain>.scienceconnect.io
HJ https://<partner subdomain>.scienceconnect.io
<partner stanza end>
AnonymousURL -*

This breakfix has been deployed to production; all three of these configs should be updated in OCLC's hosted configurations so that we don't have to maintain our own:
https://github.com/WikipediaLibrary/twlight_ezproxy/commit/ca6311e41349b462a41999cb7329033a1fb40501

In T376807#10263529, @jsn.sherman wrote:

I haven't made any changes to wiley yet, but I have put some fixes in place for T322974: PNAS resources are unavailable, T375781: Sabinet WPL resource does not work, and T363316: World Scientific access has expired

To allow cookies to pass through the scienceconnect.io oauth flow, we need to proxy the appropriate fqdn and allow anonymous access at the start of it. PNAS partially implemented the fix, but didn't have the anonymous url configured in the hosted ezproxy stanza.

AnonymousURL +https://<partner subdomain>.scienceconnect.io/api/oauth/*
<partner stanza start>
HJ <partner subdomain>.scienceconnect.io
HJ https://<partner subdomain>.scienceconnect.io
<partner stanza end>
AnonymousURL -*

This breakfix has been deployed to production; all three of these configs should be updated in OCLC's hosted configurations so that we don't have to maintain our own:
https://github.com/WikipediaLibrary/twlight_ezproxy/commit/ca6311e41349b462a41999cb7329033a1fb40501

Could you let PNAS know about this required step in the email thread I CC'd you in? Hopefully they can make further changes to the stanza and we can go back to using it.

I tested Wiley and it does appear to be working as expected now.

In T376807#10263529, @jsn.sherman wrote:

I haven't made any changes to wiley yet, but I have put some fixes in place for T322974: PNAS resources are unavailable, T375781: Sabinet WPL resource does not work, and T363316: World Scientific access has expired

To allow cookies to pass through the scienceconnect.io oauth flow, we need to proxy the appropriate fqdn and allow anonymous access at the start of it. PNAS partially implemented the fix, but didn't have the anonymous url configured in the hosted ezproxy stanza.

AnonymousURL +https://<partner subdomain>.scienceconnect.io/api/oauth/*
<partner stanza start>
HJ <partner subdomain>.scienceconnect.io
HJ https://<partner subdomain>.scienceconnect.io
<partner stanza end>
AnonymousURL -*

This breakfix has been deployed to production; all three of these configs should be updated in OCLC's hosted configurations so that we don't have to maintain our own:
https://github.com/WikipediaLibrary/twlight_ezproxy/commit/ca6311e41349b462a41999cb7329033a1fb40501

This turned about to be the essentially the correct fix for T383609: Numerique Premium WPL resource does not work as well, so we should continue to try this science connect oauth configuration as a first step if we see this occur again.