I would greatly appreciate it if people knowledgeable about the Zope user authentication process would consider helping me with a problem even though the context for the problem is extremely limited (Omniweb 10.0.5 on Mac OS X 10.0.4), because the answer will help me understand an important part of Zope in addition to helping me get past my problem and in fact, I think the answer probably has to do with the mechanism by which web browsers communicate user authorization to server-side programs generally, independent of Omniweb or Zope, so many people might find this answer interesting. I couldn't use Zope at all on Omniweb before the just released version 10.0.5, because although I could successfully connect to a specific port included in the URL, Omniweb was not using that port for the frames within the page. That seems to have been fixed with the newest version, but I still have a problem: I can successfully log in to Zope, but all attempts to use ZMI get redirected to View pages instead. I have traced through the code in ZPublisher/BaseRequest.py and ZServer/PubCore/ZServerPublisher.py to determine that the request's _auth is coming in as None in Omniweb, but a more meaningful value in other browsers. However, I'm having trouble finding where that information is coming from (the indirections in the Python code make it tricky to catch everything stepping through the code in pdb), and I've run out of time. I would GREATLY appreciate an explanation of where the authorization information is coming from. I don't see the currently logged in user in my CGI environment, including cookies. How does any server-side program get the user authorization information from the browser after the user has logged in and gone to a different frame or window? -- --- Mitchell