Problem with previewer and signed url

[Martin Schorcht]

Dear Devs,

I have a problem with using previewers on our production dataverse (https @v6.4).
On our test environment (http @v6.4 ) they run without problems (at least if I ignore mixed content or using local hosted previewers).

The problem on our production dataverse is that i get a 401 response when the tool parameters are requested:

https://prod.url.de/api/v1/files/103/metadata/96/toolparams/4?until=2025-02-07T11:45:52.365&user=privilegedUser&method=GET&token=db1395680...

--> Status 401: {"status":"ERROR","message":"Bad signed URL"}

Here is what i have checked so far:

- The previous request with callback ( https://gdcc.github.io/dataverse-previewers/previewers/v1.4/TextPreview.html?callback=aHR0cH ...) is working, also the decoded value ( https://prod.url.de/api/v1/files... ) is correct.

- The files from github.io has been loaded and cors on our minio is enabled. Also i have testet local previewer without success, so cors is devinitv not the cause of the problem.

- The users api key is refreshed (if this is relevant at all), browser cache data is cleared.

- request does not exceed the 5 min

- if I remove the parameters (user, token, ..) from the toolparams request, I get an result (200) with signedUrls of the allowed api calls (without a token parameter). As long as I am logged in, they are also working (because of the sessionid, or?).

--> Therefore, I think that the token does not work with the given adress

What could be the cause of the 401 error on the productions environment?

To describe the circumstances, I will mention the similarities and differences between prod and test, which may be relevant:

Similarities:
- both use direct upload and indirect download (direct download = false) with minio, which also works so far with webuploader

- both are connected to datacite, test-account and prod-account are working (looking at datcite fabrica)

- both are not online (atm), only accessible on local network

Differences:
- prod runs on https and test runs on http
- one minio https instance for prod and one minio http instance for test

- prod root-collection and sub-collection are not published

What might be worth mentioning is that we changed dataverse.fqdn and dataverse.siteUrl on the prod environment before creating datesets:

previously:
dataverse.fqdn = prod.old.url.de
dataverse.siteUrl = http://${dataverse.fqdn}:8080

changed to:
dataverse.fqdn = prod.url.de
dataverse.siteUrl = https://${dataverse.fqdn}

I would be grateful if you have any tips on what I could check to get to the root of the problem.

thx, martin

[James Myers]

Martin,

I’m not sure off-hand. The signed URLs work by checking a hash of the URL, so if there’s any difference between what’s signed and what’s received (things like http getting redirected to https, leaving out the /v1 when signing, etc.) the signature check will fail. Probably the easiest way to diagnose is to set FINE logging on the edu.harvard.iq.dataverse.util.UrlSignerUtil class. That should print out in the log what is being received so you can compare with the exact URL string that is being sent. Hopefully that will give you a clue about what is different in your prod environment.

 

-- Jim

--
You received this message because you are subscribed to the Google Groups "Dataverse Users Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dataverse-commu...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/dataverse-community/347a9d8a-821e-49eb-a901-7b46cbf99d75n%40googlegroups.com.

[Martin Schorcht]

Thank you Jim, Your tip was "fine" :) as the logs now show:

I'm not sure why a “http://...” comes up last. Maybe it's because our apache proxy is passing https to http? I'll ask our admin how the traffic is going. Maybe he can forward it as https? I'll let you know as soon as I know anything new.

best, martin

[Martin Schorcht]

After we followed the manual, it suddenly worked XD

The problem was that Apache communicated with payara via http (we didn't want to set up an extra certificate for Payara). 

But after reading the section about the Apache configuration under Shibboleth ( https://guides.dataverse.org/en/latest/installation/shibboleth.html#id15 ), we connected Apache to Payara via AJP,  which worked without any additional certificate :) 

best

martin