It started with a tweet on Saturday morning.
@MsIngalls: When I go to the Checklist in @Desire2Learn -when I am logged in – I get an error message that says my log in has expired – ideas? #d2l
This sounded like an issue we had in WebCT Vista product I called Failed Sessions. FSes occur when the user is actively working in the product and suddenly gets dumped to the login page. Not to be confused with Login Loop which is providing the correct username and password but never getting a valid session. I hated working either issue because they were never repeatable. The problem could involve any piece of software that could somehow touch a cookie on the user’s computer. Occasionally they were the fault of Weblogic too.
I recommended Amy open a Desire2Learn ticket through our portal on behalf of the professor. I also started my own investigation.
First, I poked around in the logging database for errors involving checklist. I found different courses not the one involved.
Second, I pulled out of our load balancer logs the id number for the course. That yielded plenty of data showing the problem.
These, I added to the ticket and suggested capturing the HTTP headers should the issue not be repeatable by others. Of course, the support agent was not able to repeat it. The headers clearly showed the cookies were not sent.
The professor of course poked holes all through my suggestions of tracking down which of the many software is involved. Different software, hardware, networks, and browsers meant the cause was probably not something residing on the computers. But the issue definitely was still all of these browsers in a wide variety of places all chose not to send the cookies. This is also when he dropped the next bomb that the problem only occurs on links in a specific widget.
Checking the code behind the widget, I only saw simple absolute URLs. Which made me shudder because earlier this week absolute URLs in the login page for a development site put me in production without me being aware for several minutes.
PSA: Only use absolute URLs when sending a visitor to another web server. Say you are here, at www.ezrasf.com and you want someone to see another of my blog entries. Drop http://www.ezrasf.com from the URL and start the path with / (a relative URL). Should I change the host name to blog.ezrasf.com or www.ezrafreelove.com, then the link has better success of working.
It turns out the problem is the professor used the pre-production host name for the web application. The widget absolute URL links used a different host name for production. Both resolve to the same servers. But cookies are tied to a specific host name. So being logged into one of host and getting a link to the variant means the session is not valid at the variant.
At least the workaround and fix are easy.
The workaround for the professor is to stop using the pre-production URL.
The fix is for the widget designer to turn the absolute URLs to relative URLs since they point to same location.
Also, it would be nice for a better error message than:
Either you have failed to login, or your login has expired.
First the comma is bad grammar. Second, if I am a normal user who encounters this problem, then what can I do to fix it myself? This is not an error someone sees if their password or username are wrong. This is also not what a user normally sees when they are idle too long. But then again, there are lots and lots of potential causes and solutions.