Page MenuHomePhabricator

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

Description

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.

Background

When accessing a resource through IP authentication, users are directed to a URL of the form https://www-website.wikipedialibrary.idm.oclc.org/. 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:

In both cases, a message should be shown to the user which says "Sorry, you are not currently authorized to access this resource."

Event Timeline

Samwalton9 triaged this task as Medium priority.Jun 5 2018, 12:40 PM
Samwalton9 moved this task from Incoming tasks to Open tasks on the Library-Card-Platform-Proxy board.
Samwalton9 added a subscriber: jsn.sherman.

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

Samwalton9 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.