User Account: Displayed user name and contact email changes from admin to another user during session (session bug)

[eaquigley]

---

Author Name: Kevin Condon (@kcondon)
Original Redmine Issue: 4096, https://redmine.hmdc.harvard.edu/issues/4096
Original Date: 2014-06-12
Original Assignee: Elda Sotiri

---

This was reported by Liz and occurred during a UX session with Gary and witnessed by Gustavo.

Gary logged in as admin on demo, performed some basic operation: create dv, checked user account page, then at some point the displayed user account changed from admin to another user. The contact email also changed to that user. When they logged out, it returned to admin.

There was an error during that session that may or may not have affected the session data.

So far we have not reproduced this. It seems to initialize the user session/ account info and then some operation incorrectly updates the session info (perhaps visiting the account page?) and logging out resets to correct values, possibly rereading from db?

Will need to reproduce.

---

Redmine related issue(s): 1096

---

[eaquigley]

---

Original Redmine Comment
Author Name: Kevin Condon (@kcondon)
Original Date: 2014-06-12T19:52:57Z

---

More user session weirdness found during UX testing:

Can't edit metadata for a study? e.g., I navigate to http://dataverse-demo.iq.harvard.edu/dataset.xhtml?id=256&versionId=86 and attempt to edit metadata. I don't really see an option to do so. I'm returned to the files section with an Information bubble that says "Edit Dataset Metadata – Add more metadata about your dataset to help others easily find it." Clicking on the Metadata tab, I am not given any way to edit the metadata. [Liz] the user may have been kicked/logged out since issue 2 indicates they need to log in again.

Related to the above, the application seems to frequently lose track of my session and I have to log in again when I am trying to edit study metadata. I don't have this exactly replicable yet.

To add to the comment above, I too seem to lose my session (suddenly cannot edit and Sign Up/Login appears at the top). Simply refreshing the page corrects this for a certain amount of time (not sure when it stops, sorry).

[eaquigley]

---

Original Redmine Comment
Author Name: Eleni Castro (@posixeleni)
Original Date: 2014-06-13T19:18:18Z

---

Same issue was reported by another user when they were testing Dataverse today.

[eaquigley]

---

Original Redmine Comment
Author Name: Philip Durbin (@pdurbin)
Original Date: 2014-06-19T12:28:44Z

---

We believe this very odd behavior of user login sessions being scrambled was due to me fronting Glassfish with Apache on http://dataverse-demo.iq.harvard.edu for #1096 and #2657. I backed out of this change the afternoon of 2014-06-13 and we haven't had any complaints since.

Next we plan to reproduce this bug on dvn-alpha, which means fronting Glassfish with Apache there. Below are instructions, such as they are.

As a side note, http://dvn-vm3.hmdc.harvard.edu already has Glassfish fronted with Apache but I've been unable to reproduce the bug there. Perhaps the problem is that I was using different browsers and not different computers.

---------- Forwarded message ----------
From: Philip Durbin [email protected]
Date: Fri, Jun 13, 2014 at 5:29 PM
Subject: how to front Glassfish with Apache

For now the documentation for fronting Glassfish with Apache is in
executable form. :)

If you type vagrant up in the root of the git repo you'll get a
CentOS VM with everything set up. Tests should even pass.

This is the file that controls what Vagrant does:
https://github.com/IQSS/dataverse/blob/master/Vagrantfile

As of this writing, four scripts are run:

https://github.com/IQSS/dataverse/blob/master/scripts/vagrant/setup.sh

https://github.com/IQSS/dataverse/blob/master/scripts/vagrant/setup-solr.sh

https://github.com/IQSS/dataverse/blob/master/scripts/vagrant/install-dataverse.sh

https://github.com/IQSS/dataverse/blob/master/scripts/vagrant/test.sh

Hopefully the scripts are pretty self explanatory but of course I'm
happy to comment them more and help with the Installers Guide.

Phil

Philip Durbin
Software Developer for http://thedata.org
http://www.iq.harvard.edu/people/philip-durbin

[eaquigley]

---

Original Redmine Comment
Author Name: Philip Durbin (@pdurbin)
Original Date: 2014-06-19T12:41:29Z

---

Philip Durbin wrote:

As a side note, http://dvn-vm3.hmdc.harvard.edu already has Glassfish fronted with Apache but I've been unable to reproduce the bug there. Perhaps the problem is that I was using different browsers and not different computers.

I just logged in a user1/user1 on http://dvn-vm3.hmdc.harvard.edu and asked Stephen to visit the homepage from his computer but he was not automatically logged in.

[eaquigley]

---

Original Redmine Comment
Author Name: Philip Durbin (@pdurbin)
Original Date: 2014-07-08T18:07:36Z

---

Elda and I are planning to try to reproduce this bug on http://api-test-dataverse.hmdc.harvard.edu once it's been set up with Apache in front on Glassfish. I'm passing this ticket to her for now since she's setting this server up.

[pdurbin]

@esotiri as we discussed, http://api-test-dataverse.hmdc.harvard.edu is set up enough to try reproducing this bug. (We plan to change the hostname but whatever.) @eaquigley and @kcondon have definitely seen this bug as well back when it was on the demo site.

[esotiri]

I will keep this open for now to see if the problem reappears as more users use the demo. Myself and other team members have not been able to reproduce the issue.

[pdurbin]

If desired, we can put Apache back in the mix on the demo site. Or on dvn-build. More people use those servers than apitest.

[esotiri]

I think its a good idea to be tested where is more trafick. I however will repetitively try on apitest machine with accounts other than pete.

[esotiri]

This is the scenario that was being followed when the issue appeared. I will test with different user accounts. Also Liz mentioned that it might have been an application time out because user was not active for close to 10-15 min.
https://docs.google.com/a/g.harvard.edu/document/d/1AJHldI8_J-ha1OWtD9jsX2KdqAzsnxlCNP2qI9jVAOI/edit

Another cause of this happening might be that full permission implementation is not in place.

[esotiri]

moving this to beta 7 - permissions completed milestone.

[pdurbin]

As we discussed, we'll try to put this through QA now as part of the effort to have the Shibboleth UI/UX in #794 demo-able in the next beta push.

[kcondon]

tested, not reproduceable

[pdurbin]

As I mentioned to @bencomp at http://irclog.iq.harvard.edu/dataverse/2014-12-11 I started a spreadsheet called Session Bug #647 Incidents.

Also, I upgraded Weld to 2.2.4 in Vagrant in 6a24028 and this change has been rolling out to various staging servers as part of the upgrade to Glassfish 4.1 in #1064.

[pdurbin]

Just an observation: during our last beta push (Beta 10), we did not happen to observe the session bug on dvn-build. (Often as we near a beta push we see the session bug because there is more traffic, generally, hitting the server.) The primary change has been upgrading Glassfish to 4.1 and Weld to 2.2.4. Of course we have no idea if this is simply a correlation.

[scolapasta]

Moving to QA, as we have not seen this since the glassfish / weld changes.

[scolapasta]

We are no longer seeing this since the weld update.

[pdurbin]

See also https://community.atlassian.com/t5/JIRA-questions/Frequent-logouts-and-Session-swap-hijack-in-JIRA/qaq-p/320125 which came in via a comment on a Google doc but I haven't really read that post in detail. For now, the solution is still to patch Weld as described at http://guides.dataverse.org/en/4.6.2/installation/prerequisites.html#installing-glassfish