Ron Klatchko wrote:
> Flappy wrote:
> > The swish-create.pl script also has a problem involving REMOTE_USER. It
> > assumes the browser sends REMOTE_USER field.
> REMOTE_USER would only be set if the directory that swish-create.pl is
> in is protected by Web authorization. Consult your Web server
> documentation on how to configure authorization for your server.
While a viable solution, it may not really be appropriate, depending on the
It sounds like overkill to require it when username/password is not the only
form of access control, and in many situations limiting access by client
hostname/address is sufficient and more convenient.
That would raise the issue of how to distinguish different users, but that
could be handled in other ways (e.g. in some circumstances, ident protocol
lookups for connections from authorised sources might be appropriate; in
other cases, it might be acceptable for the user to enter it), and in other
cases the access controls may limit access to one person or a coordinated
team who need to be treated as one person as far as setting up and managing
the web server is concerned, anyway, so that handling them as distinct
users would be precisely what they did not want.
Certainly when I get around to installing swish-e for testing on our web
server (we've been using swish for years), if we use the configuration
script at all we'd need anyone on the webmaster team to be able to work with
any search definitions.
[Yes, setting up passworded access with a single username and password shared
by all the relevant people would be possible, but it seems a bit pointless if
access is already controlled in other ways - just one more thing to remember
Flappy's suggested fix would be appropriate where access was controlled in
other ways, and all authorised users needed to share responsibility for setting
up the configuration. Assigning a dummy username (e.g. "Anonymous", mixed case
to minimise the risk of clashing with a real username if it were done in the
distributed version of the script) when REMOTE_USER is unset ought to be
sufficient.It should never get used if access *is* password controlled, and
would handle the simple case where only one person or a cooperating team was
using the script with access control is handled in other ways. My main concern
with doing that in the standard version of the script would be that people
might then set up the script with *no* access control, and not realise it was
totally insecure because it worked as expected (and in other ways too :-).
[If anyone tries using a username returned from ident lookup, beware the
risks both of odd characters in the response from ident servers that return
a token that could be used to identify the user rather than a username, and
maliciously constructed nonsense from an ident server that's been "got at" -
though if it's a trusted system, the former is more likely to be an issue
than the latter. And of course, ident is not a totally reliable means of
identification, still less authentication.]
University of Cambridge WWW manager account (usually John Line)
Send general WWW-related enquiries to firstname.lastname@example.org
Received on Fri Nov 7 13:18:49 1997