N2T links on Merritt object pages are being incorrectly redirected to merritt-aws.cdlib.org

[elopatin-uc3]

It looks like we have a problem with n2t links for Merritt ARKs. Clicking any n2t link on an object page redirects to a 401 not authorized error.

Rather than being redirected to merritt.cdlib.org, the redirect lands on merritt-aws.cdlib.org.

Here’s an example from the production demo collection: http://n2t.net/ark:/99999/fk4h14kc80

leads to a 401 here: https://merritt-aws.cdlib.org/m/ark%3A%2F99999%2Ffk4h14kc80

[elopatin-uc3]

Ask the EZID/N2T team for input on the best way to update these links. (Marisa will follow up)

Does this only apply to old objects? or are new objects exhibiting the same issue?

[marisastrong]

It is up to the identifier owner to update the links in EZID. If there are many, you can use EZID's batch tools https://github.com/CDLUC3/ezid-client-tools/

Also, EZID periodically runs a link checker and if links are broken, it would be noted in the report which is sent out. @elopatin-uc3 did we receive a link checker report from EZID recently?

[elopatin-uc3]

@marisastrong We received a link checker report on 10/12 highlighting 3666 broken links. This was generated after we switched over to the new ALBs. However, I think the link checker results are unrelated to the redirect (to merritt-aws) issue. Both old and new object pages are exhibiting the incorrect redirect now and I suspect this is global to all objects. I think we should follow up with @mreyescdl to discuss other possible culprits.

[elopatin-uc3]

@marisastrong The link checker report many eschol links in it, as well as merritt-aws.cdlib.org links. I'd rather not attach the file here, but could create an associated ticket in mrt-doc-private and post it there.

[elopatin-uc3]

Closing as duplicate