A ticket landed at the DBA’s feet having to do with users not being able to login after logout. My first thought was it had to be the custom login page. So I recommended the Branding settings be checked that the same file id was used for both the login and logout pages. They were.
Doh.
So I looked at the webserver.log and webct.log. This wasn’t the first time I’ve looked at web server logs for users who were not logged in, so my plan was just use something this to get the session id. (The username, date, and time would vary.)
SESSIONID=`grep username webserver.log* | grep 2010-08-31 | grep 16:0[78]:[0-5] | awk -F\ ’{print $5}’`
Then use this to get the web browser.
WEBBROWSER=`grep $SESSIONID webserver.log* | awk -F\” ‘{print $2}’`
Then use this to look at anything with the same browser.
grep -A 50 $SESSIONID webserver.log* | grep -A 50 $WEBBROWSER
Yeah, I know this was reeeaaaallly hokey. The web browser could be another user. The right one might not be the next one. In this case, I was dealing with a development server, so I was more confident than normal the next action would be my user.
So the logout.dowebct had an HTTP code of 200 and a GET action. The next one was a logout.dowebct with an HTTPD code of 200 and a POST action. Bingo! The user was trying to login on a logout page. No error.
Looked in webct.log for the time and there was no error for either logout. The user had a login just seconds before the first one had the familiar “invalid gotoid” which is supposedly okay. So the logs were a dead end.
Mystified by these results, I pulled up LiveHTTPHeaders and logged out and logged in again in where it failed and another institution in development where it did not fail. The failing one was sending the login to logout.dowebct. The successful one sent it to authenticateUser.dowebct.
So I was back to thinking it was the custom login page again. Over a year ago, since I have a properties file with all the relevant data, I wrote a script to generate a custom login page templates with the values filled into them for all our institutions. I hypothesized if the problem was something in the HTML, then replacing the school’s custom login page with this template at just the logout page, ought to fix the issue. It did.
Finally, I pulled up WinMerge to compare good and bad files and found the form tag contained a widget in the name attribute only when processing the logout URI. The widget was replaced with a correct value at logonDisplay. WTH? When the same HTML file used at the logonDisplay and logout URIs, they behave very differently in processing the widget. How could this be true? The System Administrator Guide (page 384) confirmed only a single widget works at the logout URL and not this one. Guess this means the Blackboard response would be this is behaving as designed.
Ah, well. We figured out over a year ago these widgets create problems for us. Guess that is still true.
