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 ---------------------------------------------