Shibboleth Developers

[Walter Hoehn <>]

I would have assumed that the filter interface would have the session 
ID and the request path as parameters and that the internal 
FilterSupport piece would determine the application ID based on the 
request map.  I guess it doesn't matter where this is handled, but it 
should be automatic, yes?

-Walter

On Dec 19, 2004, at 6:23 PM, Howard Gilbert wrote:
> A reference to a class implementing FilterSupport is supplied 
> (somehow) to
> the Filter class. It is stored in a private static field. It happens to
> point to a FilterSupportImpl that was loaded by the /shibboleth 
> context.
> Because it was loaded from the /shibboleth/WEB-INF/classes (inside the
> context) FilterSupportImpl has access to the services and objects of 
> the
> /shibboleth context, including the SessionManager and the Session 
> object
> cache. However, it only exposes the specific services that the 
> FilterSupport
> interface defines. The Filter can present a Session ID and 
> applicationId and
> get attributes for that Session object. If it doesn't know the Session 
> ID,
> it can't get anything.
>
> The application can only get data that the filter leaves for it in the
> application's own HttpSession object for this request. It has no 
> access to
> FilterSupport (which is private inside the Filter class).