Author: kbraak@gbif.org
Created: 2013-01-17 14:49:18.171
Updated: 2013-01-17 14:49:18.171
After logging into the Portal ( http://staging.gbif.org:8080/portal-web-dynamic/ ), if the user then visits Drupal ( http://staging.gbif.org/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.
[~jcuadra@gbif.org][~mdoering@gbif.org][~cvizitiu@gbif.org] Any idea why this happens?
Author: mdoering@gbif.org
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:
http://stackoverflow.com/questions/8804378/drupal-6-cas-client-wont-login-automatically
See here for the expected status:
http://dev.gbif.org/wiki/display/POR/CAS+Security
I cant find a jira ticket for this though, its definitely worthwhile having one on this so we can keep track of the status!
Author: kbraak@gbif.org
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.
[~jcuadra@gbif.org] has also encountered this error. Refreshing the browser and trying the login again fixes the problem.
Author: mdoering@gbif.org
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
Author: kbraak@gbif.org
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
Author: kbraak@gbif.org
Created: 2013-01-18 16:35:58.073
Updated: 2013-01-18 16:55:41.895
I looked at the catalina.log on cas.gbif.org 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 http://code.google.com/p/gbif-portal/source/browse/cas-server/trunk/src/main/webapp/WEB-INF/deployerConfigContext.xml right?
Please see attached extract from catalina.out that captures the failed and subsequent successful login attempts.
Author: kbraak@gbif.org
Created: 2013-01-21 15:39:39.33
Updated: 2013-01-21 15:39:39.33
Hopefully your commit ( http://code.google.com/p/gbif-portal/source/detail?r=1308 ) fixes the problem.
In further testing, [~jcuadra@gbif.org] and I also encountered some permissions problems in the Tomcat logs just like were reported here: http://stackoverflow.com/questions/9491459/jasig-cas-how-do-i-change-where-log-files-are-written-to Jose will now attempt to override the CAS log4j configuration in our WAR overlay, specifying Tomcat's logs directory. [~jcuadra@gbif.org] can you please comment further here on your work?
Author: jcuadra@gbif.org
Created: 2013-01-21 16:18:47.025
Updated: 2013-01-21 16:18:47.025
The commit is here
https://code.google.com/p/gbif-portal/source/detail?r=1309
Just added the default log4j.xml with a changed file path (as reported on the issue you posted: http://stackoverflow.com/questions/9491459/jasig-cas-how-do-i-change-where-log-files-are-written-to)
Author: cvizitiu@gbif.org
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.
Author: kbraak@gbif.org
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.
