Issue 12578

Test user logins and download authentication

Reporter: mdoering
Assignee: mdoering
Type: Task
Summary: Test user logins and download authentication
Priority: Major
Resolution: Fixed
Status: Closed
Created: 2013-01-09 11:43:00.666
Updated: 2013-08-29 14:45:11.656
Resolved: 2013-01-25 14:57:32.174

Attachment Screen Shot 2013-01-17 at 2.38.59 PM.png

Attachment Screen Shot 2013-01-18 at 11.46.55 AM.png


Created: 2013-01-17 14:49:18.171
Updated: 2013-01-17 14:49:18.171
After logging into the Portal ( ), if the user then visits Drupal ( ) they are asked to login again (see screenshot).

But strangely, after logging into Drupal, if the user then visits the Portal, they are successfully logged in, without being asked to login again.

[][][] Any idea why this happens?

Created: 2013-01-17 15:12:45.808
Updated: 2013-01-17 15:13:20.585
This is the only known bug in our setup so far. Drupals cas plugin autologin feature doesn work as expected:

See here for the expected status:

I cant find a jira ticket for this though, its definitely worthwhile having one on this so we can keep track of the status!

Created: 2013-01-18 12:22:44.865
Updated: 2013-01-18 12:22:44.865
Another bug. Occasionally an error occurs on 1st login. See screenshot.

[] has also encountered this error. Refreshing the browser and trying the login again fixes the problem.

Comment: Anything that helps reproducing the error? Or a timestamp and login name so we can dig into cas logs?
Created: 2013-01-18 12:45:48.613
Updated: 2013-01-18 12:45:48.613

Comment: I took that screenshot a couple minutes after my failed login. So, using my login name Kyle Braak, it would be my first attempt today at approximately 11:44.
Created: 2013-01-18 14:26:33.383
Updated: 2013-01-18 14:26:33.383

Created: 2013-01-18 16:35:58.073
Updated: 2013-01-18 16:55:41.895
I looked at the catalina.log on around the time of my first login this morning.

A broken pipe SocketException was encountered, when trying to lookup my user account in the Drupal DB. A simple fix to the Drupal DBCP connection params should fix this.

I encountered this before with MySQL, where the work around was to set  in right?

Please see attached extract from catalina.out that captures the failed and subsequent successful login attempts.

Comment: Yes, good catch, Kyle!
Created: 2013-01-18 18:33:48.499
Updated: 2013-01-18 18:36:07.068

Created: 2013-01-21 15:39:39.33
Updated: 2013-01-21 15:39:39.33
Hopefully your commit ( ) fixes the problem.

In further testing, [] and I also encountered some permissions problems in the Tomcat logs just like were reported here: Jose will now attempt to override the CAS log4j configuration in our WAR overlay, specifying Tomcat's logs directory. [] can you please comment further here on your work?

Created: 2013-01-21 16:18:47.025
Updated: 2013-01-21 16:18:47.025
The commit is here

Just added the default log4j.xml with a changed file path (as reported on the issue you posted:

Created: 2013-01-21 16:41:14.205
Updated: 2013-01-21 16:41:14.205
If it helps in any way: when logged in via CAS into my local Drupal install, if I go to the Drupal instance on staging, I also have to click the "Login" link.


Created: 2013-01-25 14:57:32.2
Updated: 2013-01-25 14:57:32.2
A significant amount of testing was carried out for this issue over the last couple weeks.

Logins is working fine. A separate issue addresses the last problem establishing single sign on: POR-453

Downloading is fine, except the zipped download is always a 404 response. A separate issue has been opened to address that: POR-486

Other issues with downloading include how to handle download requests for the entire index: POR-475, how to alert the user they can't download until they are logged in: POR-482, and a page where the user can view all their downloads: POR-505

Closing issue.