Shibboleth Developers

["Scott Cantor" <>]

> Enclosed is the draft API.  Scott (et al) could you let me know
> what you think?  What am I missing?  Good? Bad? Indifferent?

Some early thoughts...

Design-wise, can we merge this into the existing SHIRE and RM classes
somehow and have some of the methods common to both implementations (i.e.
the ones that don't care about the web server) and others that are specific
to each. I think that's where you're headed with the "doCheck..." stuff, but
I wasn't sure.

Re: Logging, I think we can reuse the level enum from whatever logging
library we're using (log4cpp for now) and avoid duplicating that. I also
think with maybe a small bit of work, we could implement a log4cpp Appender
that would write to the Apache log. Then more of the logging is consistent
and adjustable via the same interface. The only question is whether it would
work (not sure how it could get at the request object it needs, but there
must be some interface for that). I'll take a quick look just to see if it's
feasible.

Note that IIS has no error log (I know, it's ridiculous), so I'm using
log4cpp now anyway where applicable.

Lessee...I think we probably want to widen the API around responses a bit,
to allow for sending back responses that aren't errors, per se, so we want
some ability to influence the status code. Particularly important in the
future with SAMLv2 allowing authn requests to be form post and not redirect.

Might be reasonable also to actually wrap a real "write data" callback so
that the whole response need not be buffered ahead of time. May or may not
be important.

I need to think about the htaccess part a bit myself. I'd love to somehow
link that back to the draft API I stuck in that I know needs some changes
anyway, I'm just not sure how to bridge the two, but it ought to be
possible.

On the whole, I think this is reasonable.

-- Scott