Shibboleth Developers

["Scott Cantor" <>]

> I suppose we could try to merge some of this into the SHIRE and RM
> objects, but I'm not exactly sure if that's the right thing.  I
> suppose the doCheckAuthN() and doHandlePOST() could be in the SHIRE
> object and doCheckAuthZ() in the RM module.  Currently we're already
> using them internally, and the new APIs would still continue to use
> them, so I'd need to think a bit harder on where the lines are.
>
> The doCheck...() functions are meant to be the common implementation
> (note that they're static).  They uses the callback objects which are
> server-specific implementations.

Right, well, I think the callback object also could represent the state of
the request as well and store some of the stuff I put into the SHIRE/RM
classes. The current SHIRE/RM methods might be moved into statics or could
just be common (not virtual) implementations of methods on the callback
object.
 
> Sure it does: LogEvent().  I was modeling it after that.  The idea was

LogEvent writes to the Windows event log, which isn't a good place for debug
or trace oriented information that might plausibly be in a web server error
log. I don't use it much, and I'm not sure that you would want to implement
the IIS version of your logging callback to go there.

> to offload more logging into the standard log4cpp shire log but use
> this api for specific items to print into the webserver event log.  I
> don't think we want to have log4cpp to print into the apache log.  Nor
> do I want to print as many messages into this event log.

Well, I think it would work (I'm not saying everything would be sent there,
just specific new categories sent to that appender), but it probably doesn't
help all that much either. Particularly because I'm not sure how to
bootstrap the logging extension anyway, so it's probably not worth the
effort.

> Hmm.  Ok, do you need anything other than the status code?  Do we need
> to set the content-type, too, or is it always going to be text/html?

Probably, but I would make it a default that can be overridden just in case.
I actually would consider using the style I used in the IIS code, and
basically allow a set of headers to be provided, so that way you get more or
less full control from the portable layer.

-- Scott