Shibboleth Developers

["Scott Cantor" <>]

> Each web server module implements a subclass of the callback interface
> and creates an instance of this subclass for each request.  Obviously
> some amount of state information can go into this instance, but this
> instance is implementation-dependent.

Yes, but some of it could be implementation-independent and factored into a
base class and then only the dependent methods need to be differentied by a
subclass.

> In the apache case, I want to maintain the same subclass instance
> through the whole life of the request, which would imply that we store
> a pointer to it in the request_rec -- but that only works in apache2.
> Otherwise, we need to push state back into the request_rec so it's
> maintained between the check_user() and check_auth() apache methods.

I wasn't thinking in terms of maintaining state that way, but just using a
callback object on the stack of the filter function and then passing control
to methods on the callback object that do actual work. And in turn, they
invoke the virtual callback methods when they need something from the web
server. Since that's how the SHIRE class works now, I was trying to just
combine it. One class instead of two. But I think it works either way, see
below...

> Another thing to point out is that the current SHIRE (and RM)
> implementations require knowledge of the current application.  I'm
> trying to remove that information from the API presented to the
> webserver module implementation because that part of the processing
> really is agnostic.  Why duplicate the "get application from url" code
> in each module when you can just pass the URL and let the agnostic
> code compute the application?

Sure. But if the SHIRE object is the callback object (or I should say if the
SHIRE class is a base of the callback class) then the information and
callbacks are right there.

> But I do see your point in that I could change the SHIRE api to take a
> callback instead of an application in order to merge these functions
> into one object.  See the attached API for what I think you mean.

I'm saying combine the classes altogether, there's no function parameter
required (aside from the "this" pointer).

Something like (aside from probably changing the stupid name):

class SHIRE {
  SHIRE();
  ...
  ...non-virtual existing stuff and agnostic state...

  virtual void* doCheckAuthN();
  virtual void* doHandlePOST();
}

class ApacheSHIRE {
  ApacheSHIRE(request_rec* r);
  virtual void* doCheckAuthN();  <= these use the base class methods
  virtual void* doHandlePOST();
}

Then the module just does:

...
ApacheSHIRE obj(r);
obj.doCheckAuthN();
...

Or something along those lines, maybe even just combining the SHIRE/RM
objects and putting a pointer to a heap copy in the Apache/IIS state like
you were talking about. I'm sure I'm probably missing something, but that's
the basic direction I was thinking.

I didn't see it as radically different from what you had, apart from just
moving the statics into instance methods and optimizing out the callback
parameter.

-- Scott