system service URL formation does not take into account URL used for navigation

[j-n-c]

Using a test Dataverse installation (Dataverse 4.15 on the default por 8080 and FAKE DOI identifiers provided by default by Dataverse) I came across an issue exporting metadata for a dataset.

Steps to reproduce:

• Navigate to the dataset page (e.g. http://<ip_addr>:8080/dataset.xhtml?persistentId=doi:10.5072/FK2/IA4JR7)
• Select the Metadata tab
• Click button "Export Metadata" on the right and select a metadata schema (OpenAIRE, ...)

What happened was that I got a ERR_ADDRESS_UNREACHABLE error stating that This site can’t be reached.
The URL I was redirected to was: https://<ip_addr>/api/datasets/export?exporter=oai_datacite&persistentId=doi%3A10.5072/FK2/IA4JR7

I noticed that the API call is made using HTTPS (instead of HTTP used for navigating through the UI) and that the port (8080) had been omitted.

If I edited the API call URL to http://<ip_addr>:8080/api/datasets/export?exporter=oai_datacite&persistentId=doi%3A10.5072/FK2/IA4JR7 (change from HTTP to HTTP and add port 8080) I got an XML file with the exported metadata.

I checked the export logs in glassfish and no error was shown.

After talkin to @poikilotherm (thanks again for Your help) he pointed out that I had not set the siteUrl JVM option in domain.xml amd that because of that, as stated in the docs:

whenever the system needs to form a service URL, by default, it will be formed with https:// and port 443. I.e.,
https://{dataverse.fqdn}/
If that does not suit your setup, you can define an additional option, dataverse.siteUrl, explained below.

I stopped Glassfish, configured the siteUrl jvm option, started galssfish and the dataset metadata export began working as expected.

I believe that it would be good to either:

• Edit the configuration part of the documentation to highlight that the user may need to set the siteUrl jvm option
• Change the code to detect the protocol being used (http/https) and maybe things like the URL one is using to access the dataverse, and use that information for constructing service URLs

[poikilotherm]

I second this proposal. Creating ephemeral installations for showcases, testing etc, will most likely not have a simple FQDN, standard port and SSL around.

One could try to leave this to clever configuration magic happening during deployment.

Most certainly it will be easier to do this on the application layer, e. g. by using relative URLs, only adding overrides when explicitly configured/necessary.

[pdurbin]

Related:

• The importance of dataverse.siteUrl The importance of dataverse.siteUrl #4887
• The importance of setting dataverse.siteUrl should be emphasized in the Installation Guide The importance of setting dataverse.siteUrl should be emphasized in the Installation Guide #4517

[pdurbin]

@j-n-c hi! Are you still interested in this? Would you like to make a PR to make some of the documentation improvements you've suggested? Thanks!

[j-n-c]

Sure @pdurbin! I'll do it next week

…

On Mon, Oct 10, 2022, 13:34 Philip Durbin ***@***.***> wrote: @j-n-c <https://github.com/j-n-c> hi! Are you still interested in this? Would you like to make a PR to make some of the documentation improvements you've suggested? Thanks! — Reply to this email directly, view it on GitHub <#6071 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AEDTNVWWIJHYVXJMNLN6J2DWCQEMXANCNFSM4II5YJAA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[j-n-c]

@pdurbin, just created PR #9072