metacat icon indicating copy to clipboard operation
metacat copied to clipboard

Metacat throws the error of user not authorized during the publish process even though ezid settings are correct

Open taojing2002 opened this issue 3 years ago • 7 comments
trafficstars

Jeanette reported that she kept getting the error of user not authorized when she published a package on Arcticdata. I checked the settings and they looked good me. Restarting tomcat fixed the issue. After I looked at the code and found Metacat caches the session from the Ezid service and renews it every 24 hours. So somehow if a session is invalid before the 24 hours life (maybe the ezid service was restarted), Metacat still keeps using it. Of course the ezid service rejects its request. I am thinking Metacat should re-login when it sees the not-authroized error during the operation.

taojing2002 avatar Dec 19 '21 04:12 taojing2002

We add the code to try to log in again when the error happens.

taojing2002 avatar Mar 10 '22 00:03 taojing2002

I fixed the issue on the publish and generate methods. We should use the same strategy for the submitDOIMetadata method in the EzidDOIService class.

taojing2002 avatar Oct 19 '23 23:10 taojing2002

The error message is:

[2023-10-19 15:42:55] [info] metacat 20231019-15:42:55: [ERROR]: FAILED Request 4 for: doi:10.18739/A2Z892G9G. unauthorized [edu.ucsb.nceas.ezid.EZIDServiceRequest:run:103]

taojing2002 avatar Oct 19 '23 23:10 taojing2002

I looked at the method submitDOIMetadata closely and found that we do use the same strategy as the other methods. However, it doesn't work. The reason is, the method ezid.createOrUpdate(identifier.getValue(), metadata); creates another thread and will not throw an exception even though the saved session expires.

taojing2002 avatar Oct 19 '23 23:10 taojing2002

Since the method submitDOIMetadata can't catch the exception from another thread, the publish button and update DOI button (in the replication admin) can't force the re-login. Only the api call - generate (mint a doi) can force the re-login.

taojing2002 avatar Oct 20 '23 00:10 taojing2002

So what's the approach here to make it more robust, @taojing2002 ? The separate thread is created (IIRC) to enable a configurable number of parallel requests to EZID, so I don't think we want to remove that. Within ezid.createOrUpdate it seems like we need to be better at catching the failure and sending it up the stack so that the re-login can occur.

mbjones avatar Nov 03 '23 19:11 mbjones

During our meeting, we think we can postpone this ticket. Also I filed a ticket about this issue on the ezid repository: https://github.com/NCEAS/ezid/issues/17

taojing2002 avatar Nov 14 '23 20:11 taojing2002