The importance of setting dataverse.siteUrl should be emphasized in the Installation Guide

[ajs6f]

I installed Dataverse (4.8.3) and let some users sign up for accounts. I exposed the actual address of the application with port number, i.e. https://my.server:8080/.

The email messages being sent to users have links in them that drop the port number, i.e.

https://my.server/passwordreset.xhtml?token=blahblahblah

If Dataverse can't be exposed directly but must be proxied to port 80, that should be clearly explained in the install documentation. If it was, I missed it. Of course, it would be better for Dataverse to correct the code used to construct URLs.

Please ask me for any further information that would be useful.

[pdurbin]

I wrote http://guides.dataverse.org/en/4.8.5/installation/config.html#network-ports and I think I argue fairly strongly that putting Apache in front of Glassfish is a good idea. What I wrote there needs to be cleaned up, though. Right now I like to the Shibboleth page.

I think you can get the password resets working with a port in the URL if you include that port in your dataverse.siteUrl JVM option: http://guides.dataverse.org/en/4.8.5/installation/config.html#dataverse-siteurl

If that doesn't help, pleas let me know.

[ajs6f]

You do give that advice. You do not (to my reading) explain that the software is not functional otherwise.

At this point, users who have corrected the port number still cannot use the links because they time out after a minute or so. I can't find anything that seems relevant in the logs beyond:

[2018-03-15T20:50:00.591-0400] [glassfish 4.1] [INFO] [] [edu.harvard.iq.dataverse.timer.DataverseTimerServiceBean] [tid: _ThreadID=173 _ThreadName=__ejb-thread-pool14] [timeMillis: 1521161400591] [levelValue: 800] [[
  Behold! I am the Master Timer, king of all timers! I'm here to create all the lesser timers!]]

[2018-03-15T20:50:00.591-0400] [glassfish 4.1] [INFO] [] [edu.harvard.iq.dataverse.timer.DataverseTimerServiceBean] [tid: _ThreadID=173 _ThreadName=__ejb-thread-pool14] [timeMillis: 1521161400591] [levelValue: 800] [[
  Removing existing harvest timers..]]

[2018-03-15T20:50:00.593-0400] [glassfish 4.1] [INFO] [] [edu.harvard.iq.dataverse.timer.DataverseTimerServiceBean] [tid: _ThreadID=173 _ThreadName=__ejb-thread-pool14] [timeMillis: 1521161400593] [levelValue: 800] [[
  HarvesterService: checking timer 1]]

[2018-03-15T20:50:00.594-0400] [glassfish 4.1] [INFO] [] [edu.harvard.iq.dataverse.timer.DataverseTimerServiceBean] [tid: _ThreadID=173 _ThreadName=__ejb-thread-pool14] [timeMillis: 1521161400594] [levelValue: 800] [[
  HarvesterService: checking timer 2]]

[2018-03-15T21:50:00.577-0400] [glassfish 4.1] [INFO] [] [edu.harvard.iq.dataverse.timer.DataverseTimerServiceBean] [tid: _ThreadID=172 _ThreadName=__ejb-thread-pool13] [timeMillis: 1521165000577] [levelValue: 800] [[
  Handling timeout on si-dataverse.si.edu]]

so I'm not sure how much longer our evaluation is going to last. In any event, thank you for the pointer to dataverse.siteUrl.

[pdurbin]

Huh. Please feel free to email your server.log to support@dataverse.org and we can take a look. If there's nothing in the log we may need to increase the logging levels as mentioned at http://guides.dataverse.org/en/4.8.5/admin/troubleshooting.html#glassfish but I don't off the top of my head know the exact classes or packages to increase the levels for.

[ajs6f]

Okay, thanks. I will set up a controlled sequence that I can mark in the log transcript to show the timing of the event, but that will probably not happen before Monday, because (just to make this more pleasant) this timeout phenomenon only happens for some users.

[pdurbin]

@ajs6f ok. Thanks. Please either post the transcript here or email it, like I mentioned. I'm not sure if this will help or be more confusing, but you can see an example of setting the site URL at https://github.com/IQSS/dataverse/blob/v4.8.5/conf/docker-aio/readme.txt#L17

[ajs6f]

Thanks, @pdurbin. My concern is twofold: One, if it is the case that either that property must be set or the app must be proxied, I suggest that that should be made more clear than it is. Two, JEE gives good tools for constructing URLs, so in the absence of that property, they should be used. It seems that they are not...

[pdurbin]

I feel like @kcondon especially has reported many times that not having dataverse.siteUrl configured properly is a gotcha and I agree that this should be documented better in the guides. Maybe this issue could be pulled into a sprint to do that. I'm eager to hear other feedback on the Installation Guide as well, since you just went through it. Please feel free to leave a brain dump in this issue while it's fresh in your mind. I'd like to make it easier to install Dataverse.

I'm not sure I'm following your point about Java EE URLs. It sounds like you have some experience with Java EE? Most people who install Dataverse don't seem to have much direct experience with it.

[ajs6f]

I don't know how you are constructing your email messages, but since they are being emitted in response to an HTTP request, you should be passing through some controller technology (e.g. JAX-RS). At that stage you should be able to use JEE facilities for building URLs, which will automatically account for port numbers, context names, etc. You could use that to create URLs and send them into the mail messages instead of relying on application-specific configuration.

[ajs6f]

Thanks for the invite to braindump, but unfortunately, I actually did the install a few months ago and don't recall that much. From what I do recall, the install was not especially problematic, although I do recall wondering why a full JEE container is required but normal JEE artifacts don't seem to be provided. I would much rather have just installed my container of choice and a normal JEE deployment. Using the JEE framework but requiring a specific container (Glassfish) and offering a custom installer but no normal JEE artifacts... it's all very counterintuitive.

More pointedly, my whole purpose in this exercise is to give my institution a chance to evaluate Dataverse. That end could have been accomplished by running a VM image or using a docker-compose ensemble or by other means. I heartily commend to you the possibility of releasing such an artifact so that evaluators just don't need to do an install.

[pdurbin]

@ajs6f thanks, you've given me a lot of food for thought. I have many more questions and things to say about...

• normal Java EE artifacts and deployment
• using a Java EE container of your choice
• options for evaluating Dataverse (NDS Labs Workbench, DANS's docker-compose effort, "all in one" Docker image, Dataverse on OpenShift)

... but for the matter at hand of password reset not working when you use a port, you're completely right. It's a bug. Here's the line where the URL is constructed:

this.resetUrl = "https://" + finalHostname + "/passwordreset.xhtml?token=" + passwordResetData.getToken();

finalHostname operates on the older dataverse.fqdn JVM option and we should probably seek to eliminate that JVM option in favor of the newer dataverse.siteUrl JVM option. The former can be derived from the latter anyway. All this is just an artifact of the order in which the code was written and the fact that two different developers were working on different parts of the code at the same time in the early days of Dataverse 4 development. It's technical debt that should be paid down. I'd be happy to mentor anyone who's interested in fixing up this part of the code. Here's a link to the code above I'm talking about:

https://github.com/IQSS/dataverse/blob/v4.8.5/src/main/java/edu/harvard/iq/dataverse/passwordreset/PasswordResetInitResponse.java#L21-L42

If we do eliminate dataverse.fqdn, we need to have the installer prompt for dataverse.siteUrl instead.