@Samwalton9 Can you add some clarity on the locus of accessing unauthorized resources? Can you detail a hypothetical circumstance, wherein an end-user faces the scenario, that this ticket wishes to solve?

We talked today about how we might be able to do this with bundle partners, along with adding bundle status to the bundle partner page, but looking at the task list, I think that the best course of action might just be to send ezproxy 403s for bundle access to the homepage, as suggested by @Samwalton9. We can always circle back around for enhancement after that.

@jsn.sherman Could you add some more information here about how you envisioned this working? Susana might pick this up :)

Where the user is unable to authenticate, it's extremely straightforward to redirect them back to the platform with Deny -redirect in the ezproxy cgi authentication config
https://help.oclc.org/Library_Management/EZproxy/Authenticate_users/Directives_and_configurations_for_authentication/Common_conditions_and_actions
That's low-hanging fruit.

getting users back to the platform when they aren't authorized (eg. they don't have access to that resource group) is still pretty straightforward, but has a few more moving parts.
We'll need to create a custom ezproxy error page (logup.htm in this case) and add a meta tag to do the redirect. The trick here will be to make sure we can connect the ezproxy resource back to the partner/collection PKs in the library card platform. It doesn't look like the resource group is available as a variable in the error page template, but the starting point url (db:url) is (see https://help.oclc.org/Library_Management/EZproxy/Authenticate_users/Directives_and_configurations_for_authentication/Expressions#Variables). If I can figure out a way to get those resource group strings available to the error page, then we could parse the string and deliver nice return urls, otherwise, we'll need to make sure we have the ezproxy starting point url stored for each partner/collection in the platform, and send those in the redirect from ezproxy.

It looks like you can set custom db variables in the resource config, but maybe it's only available to the ezproxy logger?
https://help.oclc.org/Library_Management/EZproxy/Configure_resources/DbVar

Another option for us would be the description directive:
https://help.oclc.org/Library_Management/EZproxy/Configure_resources/Description

but I think that would mean we would have to stop using all of the hosted configurations so that we could insert that into the config.

I heard back from OCLC last night, and they said we should be able to use the DbVars in our custom pages, so that looks like the way to go.

Another thought - a message on Library Card could point users to (what we think is) the 'original' unproxied URL, in case the person clicking isn't a Wikipedia editor at all. As discussed elsewhere, un-proxying a URL isn't a great process, but we could make an attempt and present it in a non-definitive way.

Updating the message is very easy, but not localisable.

Really the best solution to go for is sending people to the relevant resource page. Could include a link to give people the /logout link "if you recently gained access". Might be able to update the text on the logout page to explain what just happened; to try their original link again.

Needs design.