Shibboleth Developers

[André Cruz <>]

On 2007/05/30, at 16:05, Scott Cantor wrote:

> That's why I'm using a database. It's not going to get simpler, the  
> session
> cache has to implement lookup by both session key and NameID in  
> order to
> support logout. All of that is being buried inside the API, but you  
> have to
> support the features. I group session data into a context per session,
> that's why I have to have those methods.
>
> And I'll warn you that updating the expiration of the context has  
> to be
> fast, you have to do it on every request to enforce inactivity  
> timeouts.

If each session will have it's own context then I can use the context  
as a key to memcache and store a hashtable with the second level keys  
and values. This way I don't have to search as I have quick access to  
a whole context. What do you think?

> > Also, if we ever get this to work, will it be possible to share this
> > cache among various SPs of different applications or will their
> > contexts clash?
>
> Depends on the component using it. The session cache uses the  
> session key as
> a context, so it's unique. Other contexts probably will have a  
> fixed value
> but will be storing non-overlapping data, unless people are generating
> conflicting assertion IDs or artifacts. You can search the code to  
> see all
> the create calls.

What you're saying is that the other caches besides the session cache  
will store everything in a single context per cache? This way the  
context object will become pretty big to be stored as a whole... humm..

As a side note. Is it possible to build the current trunk shib sp? I  
checked out all of the repositories but had some problems generating  
the makefiles...

Thanks,
André