Page MenuHomePhabricator

Direct users to appropriate locations if they are not approved for access to a proxied resource
Open, MediumPublic


User story: As a Library Card user, if I click a proxied URL to which I'm not authorized, I want to be directed to a page which explains how to become authorized so that I can do so.


When accessing a resource through IP authentication, users are directed to a URL of the form This sends them through our EZProxy server for authentication. If they are not authenticated for access, users currently receive an error message page: We are sorry, but your account does not have access to this resource. If you think you have reached this screen in error or have questions about the resource you were trying to reach, please contact your library. No further guidance is given on why the user is seeing this error, or how they can get access to this resource.

Instead of showing the user an EZProxy error, we should do one of two things depending on the partner's authorization method:

Event Timeline

@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
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 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?

Another option for us would be the description directive:

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.

Samwalton9-WMF renamed this task from Direct editors to appropriate locations if they are not approved for access to a resource to Direct users to appropriate locations if they are not approved for access to a resource.Mar 30 2021, 8:35 AM

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.

Samwalton9-WMF renamed this task from Direct users to appropriate locations if they are not approved for access to a resource to Direct users to appropriate locations if they are not approved for access to a proxied resource.Aug 30 2021, 11:15 AM
Samwalton9-WMF updated the task description. (Show Details)
This comment has been deleted.