Re: checklink credits

On Mon, 2004-01-05 at 04:22, Olivier Thereaux wrote:
> On Sat, Dec 13, 2003, Ville Skyttä wrote:
> 
> > BTW, the CVS version of checklink contains an embedded manual page which
> > has a AUTHOR section, currently mentioning Hugo, Renaud, me, Frédéric
> > and "many other volunteers".
> 
> Indeed. Which does not preclude us from updating the credits in the HTML
> documentation.

But of course not, just pointing it out hoping that they'll be
consistently listed $whereverTheyAre.

> > I think the CPAN dependencies-only approach works better for the
> > validator and checklink due to configuration issues and the need for
> > external binaries which obviously cannot be handled by CPAN. 
> 
> I think I misunderstood it at first, but my understanding of it, now, is
> that unlike the validator (with its dependencies) checklink could be
> distributed as a CPAN module and not just a bundle to take care of
> dependencies, right?

Right.  There has been some discussion about integrating the checklink
docs more closely with the validator's, but as of now it's self
contained IIRC.  I think that the CPAN "full" checklink distribution is
a good idea.

>  (though I reckon that the config file might be an
> issue).

Not currently, as the config file is completely optional; without it
sane defaults will be used.  See commentary in the BEGIN block of
W3C::CheckLink.

> I must confess partial ignorance of this trusted domain. I know from the
> code that this trusted domain will be passed authentication information,
> but I am still fuzzy on the details. The current prod version does seem
> to forward authentication to my private domain even though it is not at
> w3.org, so maybe I am missing the point.

Unless configured otherwise, the basic authentication should only be
sent to URLs on the same host which initially asked it (ie. in CGI mode,
the host of the initial URL given; in command line mode it does not have
to be the initial URL because we can prompt for the info later).

If Trusted is set, basic auth info will be forwarded *only* to URIs
matching that regexp.  Note that this means that if the first requested
link to be checked does not match, it will not receive the auth info
either -> no link checking.  This is a somewhat draconian approach
though, admitted.

Note also that since 1.3.$something, Apache needs to be built with
-DSECURITY_HOLE_PASS_AUTHORIZATION or checklink will need to be running
under mod_perl, otherwise the basic auth forwarding trickery will not
work at all.  More info:
http://httpd.apache.org/dev/apidoc/apidoc_SECURITY_HOLE_PASS_AUTHORIZATION.html
I don't know why v.w.o does not seem to be affected, in theory I believe
basic auth forwarding for validator and checklink should not work at all
there at the moment.

(The validator is bitten by this too, BTW, and the mod_perl workaround
has not been implemented in it at the moment.  And yes, this should be
documented somewhere ;)

> There was no answer to my (probably clueless) suggestion at
> http://lists.w3.org/Archives/Public/public-qa-dev/2003Jan/0018.html
> so I gather it is not possible to set a trusted domain in the query
> string (makes sense)...

Yep, not currently possible.  I do think that the value needs to be a
regular expression to be powerful enough, but on the other hand letting
end users specify (== override the sysadmin's setting) it at least needs
some thought.

>  In such a case, I need to understand the details
> of how having a trusted domain is a problem for other domains, and how
> not having one would be an issue for W3C internal use before having a
> clear opinion... I think it would be possible, though perhaps sensitive,
> to have a specific instance for internal (comma tool) use, though.

In addition to the above, I believe W3C users typically want the
authorization information sent to the whole .w3.org domain, that's at
least what the old hardcoded default was.  Now, if checklink is
configured to send it only to .w3.org, such a service would not be too
useful for non-W3C folks wrt basic authentication forwarding.

Received on Monday, 5 January 2004 19:19:38 UTC