-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I just wanted to let you all know that a reboot of the system caused this problem to go away. We do not know whether it was java, tomcat, or the system that was causing this issue. We are not confident that we can ever replicate it (though we will try), but it may be an accumulating login issue perhaps.
Given that we have modified CAS, there's no guarantee whether the issue is introduced by our code, or not. And, given that we can't reproduce it, it's really difficult to determine whether it has to do with CAS, or our changes. We are moving to a newer environment, because we need to anyhow. In addition, I plan on automating a whole bunch of logins over and over again, to see if the problem starts happening again. Trenton D. Adams wrote: | Thanks Andrew, | | but, we are only running 2.0.11, so we don't have those options as far as I know. | | ----- "Andrew R Feller" <[EMAIL PROTECTED]> wrote: |> Hi Trenton, |> |> What version of CAS are you using? What type of timeout policy do |> you |> expect CAS to have? |> |> By default, the TGT is configured to use an expiration policy that |> expires TGTs if the user has been idle for X amount of time. There |> are |> several other expiration policies available with CAS including: |> |> 1. MultiTimeUseOrTimeoutExpirationPolicy |> 2. NeverExpiresExpirationPolicy |> 3. ThrottledUseAndTimeoutExpirationPolicy |> 4. TimeoutExpirationPolicy |> 5. HardTimeoutExpirationPolicy (new with CAS 3.2) |> |> Depending on your version of CAS, this is configured within either |> /WEB-INF/applicationContext.xml or |> /WEB-INF/spring-configuration/ticketExpirationPolicies.xml under the |> bean with the id of "grantingTicketExpirationPolicy". |> |> HTH, |> |> Andrew R Feller, Analyst |> University Information Systems |> 200 Fred Frey Building |> Louisiana State University |> Baton Rouge, LA, 70803 |> (225) 578-3737 (Office) |> (225) 578-6400 (Fax) |> |> |> -----Original Message----- |> From: [EMAIL PROTECTED] |> [mailto:[EMAIL PROTECTED] |> On Behalf Of Trenton D. Adams |> Sent: Monday, March 17, 2008 12:58 PM |> To: Yale CAS mailing list |> Subject: CASTGC does not timeout |> |> Hi Guys, |> |> We're running tomcat 4.0.x with Java 1.4.1. I have been doing tests |> with session timeouts, as people have been complaining that sessions |> don't timeout for many hours. |> |> So, I wrote a script to test it with wget. |> |> The credentials file looks like |> 'username=username&password=password'. |> The command line looks like this... |> |> sessionTimeoutTest.sh 172800 172800 /tmp/login.html |> /tmp/wget-session.log /tmp/wget.cookies |> https://secure.athabascau.ca/cas/login /tmp/credentials.txt |> |> So, after 48 hours, the CAS session has not timed out. When I use |> our |> test environment, which unfortunately is different because we are |> running production CAS on a legacy environment, it times out in 7200 |> seconds (+/- 60) as expected. The test environment is tomcat5 and |> Java |> 1.4.2 |> |> FYI: This machine has been restarted recently as well, and it is not |> under very heavy load. |> |> Does anyone have any clue what is happening? We're thinking that an |> upgrade is in order, but would like to know why this is happening. |> |> #!/bin/sh |> |> # args timeout increment output.html logfile.log cookiefile url |> credentials.txt |> |> TIMEOUT=$1 |> INCREMENT=$2 |> OUTPUT=$3 |> LOGFILE=$4 |> COOKIEFILE=$5 |> URL=$6 |> CREDENTIALS=$7 |> |> wget --no-check-certificate -o $LOGFILE -O $OUTPUT \ |> --keep-session-cookies --load-cookies=$COOKIEFILE \ |> --save-cookies=$COOKIEFILE "${URL}`cat $CREDENTIALS`" |> |> NOTTIMEDOUT=true |> TOTALTIME=0 |> while $NOTTIMEDOUT -eq 'true'; do |> echo "Testing timeout at $TIMEOUT seconds"; |> sleep $TIMEOUT |> ((TOTALTIME += $TIMEOUT)); |> wget --no-check-certificate -o $LOGFILE -O $OUTPUT |> --keep-session-cookies \ |> --load-cookies=$COOKIEFILE --save-cookies=$COOKIEFILE "$URL" |> grep 'You have been logged' $OUTPUT |> if [[ $? -ne 0 ]]; then |> NOTTIMEDOUT=false |> echo "Timeout at $TIMEOUT"; |> echo "Total time: $TOTALTIME"; |> fi |> ((TIMEOUT += $INCREMENT)); # up the session test in 15 minute |> intervals |> done; |> |> |> __ |> This communication is intended for the use of the recipient to |> whom |> it |> is addressed, and may contain confidential, personal, and or |> privileged |> information. Please contact us immediately if you are not the |> intended |> recipient of this communication, and do not copy, distribute, or |> take |> action relying on it. Any communications received in error, or |> subsequent reply, should be deleted or destroyed. |> --- |> _______________________________________________ |> Yale CAS mailing list |> [email protected] |> http://tp.its.yale.edu/mailman/listinfo/cas |> _______________________________________________ |> Yale CAS mailing list |> [email protected] |> http://tp.its.yale.edu/mailman/listinfo/cas | | _______________________________________________ | Yale CAS mailing list | [email protected] | http://tp.its.yale.edu/mailman/listinfo/cas - -- Trenton D. Adams Systems Analyst/Web Software Engineer Navy Penguins at your service! Athabasca University (780) 675-6195 :wq! -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.7 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFH/nYby1ltpSlXkf8RAmXBAKDwYrZ98zQJXIzK51qD+pprEgJ4IQCfSpbT 5nQblnjH638+bIL2SaNzQ4o= =xnjv -----END PGP SIGNATURE----- _______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
