Hi,
I can see that it is difficult to implement this, but I'll try later. Now I need to know if a user is active or not. I'm thinking of sending the login or the ticket to the CAS server. What is the method that validates if the ticket is valid? This functionality is not done by a user but an application that will need to know if a user is currently active. The application will know the login and the ticket. Thanks. De: Scott Battaglia [mailto:[email protected]] Enviado el: miércoles, 12 de enero de 2011 22:02 Para: [email protected] Asunto: Re: [cas-user] Know which users are connected For 4.0, we currently have: 1. InMemory (which even though there is no API, we can traverse it) 2. EhCache 3. Infinispan 4. JPA (implicit support) 5. Memcached (laughs at our attempts to query) BerekelyDB at the moment has not been ported. I don't believe EhCache or Infinispan really recommend going through all the entries. Inmemory we could write our own. JPA has some natural support. Memcached will laugh at us. I think the first thing to do is look at common queries people want to do. The one that came up and is currently supported is if you known a user id, find all their sessions. It was easy to support but its not easily generalizable. We might want to move this to -dev at this point also :-) Cheers, Scott On Wed, Jan 12, 2011 at 3:56 PM, Marvin Addison <[email protected]> wrote: > http://code.sixapart.com/svn/memcached/trunk/server/doc/protocol.txt Thanks for that -- learned something. > No its not reasonable if the bulk of the mechanisms don't support some it > internally (like JPA does). For 3.4, it's better than 50/50 since both JPA and BerkeleyDB naturally support querying. You could possibly build a query API for JBossCache since it does support iteration over cache entries by walking the tree. I've seen no warnings about that operation, but I haven't really looked. For 4.0, I'm not certain whether we'll port BerkeleyDB, so it may leave JPA as the only storage mechanism with natural support for querying. In any case my impression from cas-user posts is that JPA is one of the more popular choices for ticket storage, so we shouldn't be shy about developing features that may provide important or interesting functionality based on it. In the name of generalization, we should consider a QueryableSessionStorage subinterface of SessionStorage that can service queries. M -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
