[Zope] Zope, Apache/NT, Reliability issues

[Martijn Pieters]

On Fri, Jun 09, 2000 at 02:50:26AM -0400, J. Michael Mc Kay wrote:
> Can I jump in?
> 
> What is the process involved for pcgi or Zope to pass authentication?  I am
> not running Apache, but good old dependable Website Pro. When I attempt to
> run Zope via pcgi it works fine unless I want to manage or allow a client to
> log into a products administration screens.  I am returned an error when
> trying to access, for example, Squishdot admin or Zope manage. On the other
> hand users can log into and use the portal product.
> 
> Zope is not accepting the management login info. My understanding is not
> clear on what Apache does to accept log ins via pcgi.  For that matter the
> same for IIS. I am not sure that IIS is really only accepting NTusers. The
> reading I have done so far suggests this may be the case.
> 
> Zope & Apache are HTTP1.1 compliant? Website is 1.0 or partially 1.1.......
> can this be part of the problem?  I run into some problems with requests and
> compliancy when using newer utilities against the server.
> 
> The conversation below suggests that pcgi passes requests to Zope.  I am
> confused about this because I am told this is a Website issue, but when
> explained in it's simplest terms (below) it appears to be a pcgi or Zope
> issue.
> 
> The error I am receiving says that the webserver may not be able to forward
> cgi requests (? it's been awhile since I looked at it) This doesn't make
> sense if pcgi is  passing the info on. I guess I am asking "Where exactly is
> authentication breaking down when using pcgi....or where is it most likely
> to break down?
> 
> Website has only 15 percent of the NT market share (it's the price tag I'm
> sure) and it is hard to find someone to share these experiences with, so
> thanks for allowing this intrusion..

CGI scripts traditionally get a predigested version of the headers the client
hands in. On many web servers, this _doesn't_ include the authentication
headers, which are crucial for handling password authenticated parts of your
website. Most servers will try and handle this information themselves, and
only hand the CGI script a new header, 'HTTP_REMOTE_USER', IIRC, that contains
the name of the authenticated user. This is desireable for many CGI scripts
when you don't want to have to code authentication libraries.

However, it is a pain when you have a system like Zope, that _is_ very capable
of handling this kind of authentication by itself. For different servers,
different tricks need to be employed.

On Apache, you can use a rewrite rule to make a copy of the Authorization
header and pass the copy in as 'HTTP_CGI_AUTHORIZATION'. On IIS, if you
specify no password protection for the PCGI stub, it gets handed the proper
headers quite nicely. IIS does interfere with the Zope 401 status message,
you'll need to switch that off. On Roxen, I believe there is a configuration
setting called 'Raw user info' for this. And Netscape requires a NSAPI plugin
to pass on the information.

Now, it sounds like Website doesn't pass in the Authorization header either.
Unfortunately, I don't know enough about Website Pro to be able to say wether
or not you can make it pass the header anyway, and what tricks are needed to
make it so. You will need to consult the Website Pro manuals for that. I hope
that my explanation has given you enough pointers to help you out here.

There is an alternative to passing in the Authorization header however, and
that's having Zope use REMOTE_USER. Your webserver will then do the
authentication, set the REMOTE_USER variable, and Zope will try and find a
User object that matches that user name. See doc/WEBSERVER.txt for more info
on this.

-- 
Martijn Pieters
| Software Engineer    mailto:mj@digicool.com
| Digital Creations  http://www.digicool.com/
| Creators of Zope       http://www.zope.org/
|   The Open Source Web Application Server
---------------------------------------------