On Fri, May 03, 2013 at 11:27:01AM -0400, Whittaker, Geoffrey wrote:
> I'm having an intermittent problem with Tomcat/CAS were sometimes I'll click a
> link or button, etc and the page will flash like it's doing a GET/POST and
> then nothing happens.
Hi, I just discovered when this happens, Java
Hi,
Where can I contribute a more complete translation of messages_es.properties?
--
---
Alberto Cabello Sánchez
albe...@unex.es
--
You are currently subscribed to cas-user@lists.jasig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, se
I'd update to be either:
1. Create a JIRA issue and attach the new translation (
http://issues.jasig.org)
2. Fork the CAS project on GitHub and send a pull request
#2 is the one that makes everyone's lives easier (assuming you have a
GitHub account)
:-)
Cheers,
Scott
On Wed, May 8, 2013 at 7
I guessed "fork" stood for "github fork" ;) which by the way solves my problem
"how to get CAS sources", as the link in https://wiki.jasig.org/display/CAS/Home
pointing to http://www.ja-sig.org/products/cas/developers/cvs/index.html
is not accurate.
I think I just requested pull.
Thanks, Jérôme a
I pdated that link, thanks!
On Wed, May 8, 2013 at 8:12 AM, Alberto Cabello Sánchez wrote:
> I guessed "fork" stood for "github fork" ;) which by the way solves my
> problem
> "how to get CAS sources", as the link in
> https://wiki.jasig.org/display/CAS/Home
> pointing to http://www.ja-sig.org/
Good morning,
We have a hardware load balancer/proxy that we'd like to use for a distributed
deployment of CAS using a central database. While we were discussing it this
morning, we stumbled on the question of whether or not CAS will have a problem
with all of the connections having the same s
Geoff,
Ehcache seems to perform better than using a database (JPA), there is also
jboss, memcache etc. I am sure you will get lot's of replies as there seems to
be quite a few that have set it up this way. We are using a Cisco ACE LB
hardware for our setup (ehcache for tickets, json for servic
Hello Geoff. Agreeing with Scott here about EHCache over a DB. We implemented
what you describe with a single VIP to our (ACE) load balancer with two CAS
servers behind the load balancer and with EHCache instead of a DB for the
tickets cache. It's been in place since the first of the year wit
Scott - Do you all use distributed ehcache for this? Otherwise how would
each server in the cluster be aware of the tickets for the callback? I'd
be interested in switching to an in-memory solution if others have had
positive results.
The tricky thing about CAS is making sure when a client calls
Christian,
The typical recommendation is to generate a unique token and store that
somewhere (i.e. a database along with the associated principal) and have a
non-interactive CAS authentication handler read that value and return the
principal. This has been asked enough times that we should probab
Adam, Yes that is how it works, they are distributed and stored in memory and
are replicated between the cluster members. Also I think an additional benefit
is not needing a ticket registry cleaner, which seems to have presented some
institutions problems with performance.
The jasig wiki has
Just to be clear: any registry that doesn't rely on a registry cleaner may
or may not exactly respect your expiration policies since their internal
clean up mechanisms may clear out your ticket before its actually time
expired (this means Memcache, EhCache, etc.). In practice, its not a huge
issue
We did an implementation in cassandra where we set the TTL (time-to-live)
for the row containing the ticket based on the remaining time to expire for
that ticket. When the last use time of the ticket was updated, we updated
the row to push out the TTL. In order to so this, I believe that we had t
13 matches
Mail list logo
