[Zope3-dev] HTTPRequest object broken when not used w/zope.server

Albertas Agejevas alga@codeworks.lt
Tue, 1 Jul 2003 11:17:15 +0300


On Wed, Jun 25, 2003 at 01:59:56PM -0400, Phillip J. Eby wrote:
> The 'setUser' method of HTTPRequest does this:
> 
> self.response._outstream.setAuthUserName(user.getId())

Yup, I'm responsible for this code and I admit that it's ugly.

I've been banging my head on the problem for about a week, but then
gave up and did an obviously dirty thing.

As Shane correctly points out, the whole thing is used for logging the
user name in the HTTP hit log.

The zope.server has all the ends:  it instantiates the request,
invokes the publication, and does the logging, but it's such a tight
tangle of obscure factories, that I don't grok it well enough to be
able to refactor it to do the right thing WRT logging the user names.

I've been trying to maintain due diligence, was asking Jim on IRC,
etc.  Unfortunately, we haven't come to any conclusion.

> This is pretty bogus, since AFAIK there is no requirement that the user 
> object of a request should even have a 'getId()' method,

The IPublicationRequest.user is IPrincipal wrapped in a context of its
authentication service for some time now.

> and of course the 
> requirement that 'response._outstream' have a 'setAuthUserName()' method 
> doesn't work with CGI or FastCGI publishing (which until now I've been able 
> to do with Zope 3).

But all the tests still pass, right? <wink>

On Wed, Jun 25, 2003 at 02:30:30PM -0400, Shane Hathaway wrote:
> I think the response should have two attributes rather than one: 
> "outstream" and "http_transaction".  The outstream attribute should 
> always exist.  The http_transaction attribute should point to an object 
> that represents the HTTP transaction (currently called a "task" in 
> zope.server) or None.  The two attributes might refer to the same 
> object.  The above code should then look like this:
> 
> if self.response.http_transaction is not None:
>     self.response.http_transaction.setAuthUserName(user.getId())

This looks like a good idea, I'll try to implement this.

Albertas
-- 
Si hoc legere scis, nimium eruditionis habes.