Z2.log logs user as Anonymous
Hi, I've got CookieCrumbler installed with my Zope site in order to carry out user authentication. My users can initally register to the site - they are added to the acl_users folder in this step. From then on they can log into the site as registered users.... all works fine till here. The only problem is with my Z2.log... the zope access log. I'd like to use this to gather some statistics about which users log in most frequently etc. What's happening though is that when a user logs into the site and continues browsing through it, the z2.log keeps logging the user as "Anonymous". The only time this changes is when I use the ZMI and in that case the log lists the user as 'admin'. Can anyone tell me what I'm missing? Cheers Ruth
On Thu, Oct 16, 2003 at 12:01:33PM +0200, Ruth Mizzi wrote:
The only problem is with my Z2.log... the zope access log. I'd like to use this to gather some statistics about which users log in most frequently etc. What's happening though is that when a user logs into the site and continues browsing through it, the z2.log keeps logging the user as "Anonymous". The only time this changes is when I use the ZMI and in that case the log lists the user as 'admin'.
Can anyone tell me what I'm missing?
As I understand it, if an object is anonymously accessible, Zope skips the authentication / authorization process. A logged-in user might as well be anonymous unless they are looking at an object which requires authorization. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's SPARKLING SPASTIC ADMIRAL! (random hero from isometric.spaceninja.com)
Hi, Paul Winkler wrote:
On Thu, Oct 16, 2003 at 12:01:33PM +0200, Ruth Mizzi wrote:
The only problem is with my Z2.log... the zope access log. I'd like to use this to gather some statistics about which users log in most frequently etc. What's happening though is that when a user logs into the site and continues browsing through it, the z2.log keeps logging the user as "Anonymous". The only time this changes is when I use the ZMI and in that case the log lists the user as 'admin'.
Can anyone tell me what I'm missing?
As I understand it, if an object is anonymously accessible, Zope skips the authentication / authorization process. A logged-in user might as well be anonymous unless they are looking at an object which requires authorization.
the problem here is the use of cookie based authentication. so the user info is not in the http authentication header, which is where the user in the logs come from. So you have the choice: 1. user names in the logs -> dont use cookie base authentication 2. cookie based authentication (login with forms) - >no user names in logs Ciao, Jochen -- -------------------------------------------------- Jochen Knuth WebMaster http://www.ipro.de IPRO GmbH Phone ++49-7152-93330 Steinbeisstr. 6 Fax ++49-7152-933340 71229 Leonberg EMail: J.Knuth@ipro.de
On Thu, Oct 16, 2003 at 07:23:24PM +0200, Jochen Knuth wrote:
the problem here is the use of cookie based authentication. so the user info is not in the http authentication header, which is where the user in the logs come from. So you have the choice:
1. user names in the logs -> dont use cookie base authentication 2. cookie based authentication (login with forms) - >no user names in logs
That may be, I don't use cookie auth much. Even so, I believe that anonymously accessible objects will *always* be logged as Anonymous. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's PYRO BOAT LIUTENANT! (random hero from isometric.spaceninja.com)
I had the same problem which was solved by pault. i have patched the version of ZServer I use to handle the logs properly. Here's Paul's "shameful fix". It works for Zope 2.5.1 through 2.6.2b3. Subject: Re: Z2.log user name problem From: Paul Tiemann <pault@center7.com> To: Dennis Allison <allison@sumeru.stanford.EDU> Cc: zope@zope.org
I'm using out-of-the-box user authentication with CookieCrumbler. Everything seems fine except that the identified user in the Z2.log file is wrong.
I've got a "fix" for your problem. It wouldn't have been my first choice to do it the way I did, but it works, and it's quicker than my other options were... (Some history) I had the same problem with cookie-based authentication. The root of the problem lies in the log() method of the file ZServer/medusa/http_server.py. That method uses the 'Authorization' header of the request to determine the name of the user. Due to the architecture of the internal objects used to represent the request at this level (not the "REQUEST" we're usually used to using, but another lower-level request object) the 'Authorization' header is a read-only field. I believe it's the __get_item__ and __set_item__ methods that are custom for that request object, so that all attempts to "set" the Authorization HTTP header will just be dumped into the list of response headers. Since I could see no other way to get around the problem by making a change in the 'CookieCrumbler', or in my case 'LDAPUserFolder' products, I decided to just fix the problem by monkey-patching the log() method in the http_server.py file itself. To do that, you can do something like this: 1) Add two lines like these to the top of http_server.py for the import you'll need below to make parsing the cookies easier. # PAUL DID THIS SHAMEFUL THING from ZPublisher.HTTPRequest import parse_cookie 2) Down near line 290, you have the part that determines the name that will go to the Z2.log file. Here, you see 'name' being set to 'Anonymous', then there is an 'if auth is not None:' block which determines the name from the "Authorization" header. In my case, I added an 'else:' block below the if which has this dirty patch of code: try: auth_cookie_name = "my_auth" # probably '__ac'? cookie = None try: cookies = {} header_value = self.get_header("Cookie") if header_value: parse_cookie(header_value, cookies) cookie = cookies.get(auth_cookie_name, None) except: name = "Anonymous" if cookie is not None: cookie = unquote( cookie ) try: cookie = base64.decodestring( cookie ) name, password = tuple( cookie.split( ':', 1 ) ) except: name = "Unknown (bad auth cookie)" except: name = "Failure!" Note that the way I solved the problem is "brittle" because should you ever change your auth_cookie_name, and forget to change it in http_server.py as well, you'll stop seeing correct values in your logs. One more important note: Since you have more than one acl_users, you might want to put the 'Cookie' based name-fetch code before the 'Authorization' header based stuff. It would be possible for you to log in as admin, then use the cookie-based login page to authenticate as a normal user, in which case your browser will be sending the 'Authorization' header, as well as the cookie, and that would cause the standard acl_users username to be logged...
I assume there is some method which needs to be called to update the username for logging purposes when the login is upgraded, but I've been unable to find it. Or is this a problem caused by the lack of a CookieCrumbler in the root folder....
I tried to find a method like the one you're describing, and one alternative to my solution would have been to add that kind of facility to the low-level request object, and make different changes to http_server.py so it would get the user's name from that new variable instead of from the Authorization header, but I couldn't find it, and it didn't appear that CookieCrumbler was doing that either... If there is an alternative solution that is more desirable than my own, I would love to hear about it... Maybe someone on the list knows another way... Good luck, I hope I've helped, ;) Paul On Thu, 16 Oct 2003, Paul Winkler wrote:
On Thu, Oct 16, 2003 at 07:23:24PM +0200, Jochen Knuth wrote:
the problem here is the use of cookie based authentication. so the user info is not in the http authentication header, which is where the user in the logs come from. So you have the choice:
1. user names in the logs -> dont use cookie base authentication 2. cookie based authentication (login with forms) - >no user names in logs
That may be, I don't use cookie auth much. Even so, I believe that anonymously accessible objects will *always* be logged as Anonymous.
--
Paul Winkler http://www.slinkp.com Look! Up in the sky! It's PYRO BOAT LIUTENANT! (random hero from isometric.spaceninja.com)
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
You know, I think I've been wrong all along. Reading the below reminded me that I was thinking of the current user object in zope, not the username that's logged. Oops. On Thu, Oct 16, 2003 at 01:21:20PM -0700, Dennis Allison wrote:
I had the same problem which was solved by pault. i have patched the version of ZServer I use to handle the logs properly. Here's Paul's "shameful fix". It works for Zope 2.5.1 through 2.6.2b3.
Subject: Re: Z2.log user name problem From: Paul Tiemann <pault@center7.com> To: Dennis Allison <allison@sumeru.stanford.EDU> Cc: zope@zope.org
I'm using out-of-the-box user authentication with CookieCrumbler. Everything seems fine except that the identified user in the Z2.log file is wrong.
I've got a "fix" for your problem. It wouldn't have been my first choice to do it the way I did, but it works, and it's quicker than my other options were...
(Some history) I had the same problem with cookie-based authentication. The root of the problem lies in the log() method of the file ZServer/medusa/http_server.py. That method uses the 'Authorization' header of the request to determine the name of the user. Due to the architecture of the internal objects used to represent the request at this level (not the "REQUEST" we're usually used to using, but another lower-level request object) the 'Authorization' header is a read-only field. I believe it's the __get_item__ and __set_item__ methods that are custom for that request object, so that all attempts to "set" the Authorization HTTP header will just be dumped into the list of response headers. Since I could see no other way to get around the problem by making a change in the 'CookieCrumbler', or in my case 'LDAPUserFolder' products, I decided to just fix the problem by monkey-patching the log() method in the http_server.py file itself.
To do that, you can do something like this:
1) Add two lines like these to the top of http_server.py for the import you'll need below to make parsing the cookies easier.
# PAUL DID THIS SHAMEFUL THING from ZPublisher.HTTPRequest import parse_cookie
2) Down near line 290, you have the part that determines the name that will go to the Z2.log file. Here, you see 'name' being set to 'Anonymous', then there is an 'if auth is not None:' block which determines the name from the "Authorization" header. In my case, I added an 'else:' block below the if which has this dirty patch of code:
try: auth_cookie_name = "my_auth" # probably '__ac'? cookie = None try: cookies = {} header_value = self.get_header("Cookie") if header_value: parse_cookie(header_value, cookies) cookie = cookies.get(auth_cookie_name, None) except: name = "Anonymous"
if cookie is not None: cookie = unquote( cookie ) try: cookie = base64.decodestring( cookie ) name, password = tuple( cookie.split( ':', 1 ) ) except: name = "Unknown (bad auth cookie)" except: name = "Failure!"
Note that the way I solved the problem is "brittle" because should you ever change your auth_cookie_name, and forget to change it in http_server.py as well, you'll stop seeing correct values in your logs.
One more important note: Since you have more than one acl_users, you might want to put the 'Cookie' based name-fetch code before the 'Authorization' header based stuff. It would be possible for you to log in as admin, then use the cookie-based login page to authenticate as a normal user, in which case your browser will be sending the 'Authorization' header, as well as the cookie, and that would cause the standard acl_users username to be logged...
I assume there is some method which needs to be called to update the username for logging purposes when the login is upgraded, but I've been unable to find it. Or is this a problem caused by the lack of a CookieCrumbler in the root folder....
I tried to find a method like the one you're describing, and one alternative to my solution would have been to add that kind of facility to the low-level request object, and make different changes to http_server.py so it would get the user's name from that new variable instead of from the Authorization header, but I couldn't find it, and it didn't appear that CookieCrumbler was doing that either...
If there is an alternative solution that is more desirable than my own, I would love to hear about it... Maybe someone on the list knows another way...
Good luck, I hope I've helped, ;) Paul
On Thu, 16 Oct 2003, Paul Winkler wrote:
On Thu, Oct 16, 2003 at 07:23:24PM +0200, Jochen Knuth wrote:
the problem here is the use of cookie based authentication. so the user info is not in the http authentication header, which is where the user in the logs come from. So you have the choice:
1. user names in the logs -> dont use cookie base authentication 2. cookie based authentication (login with forms) - >no user names in logs
That may be, I don't use cookie auth much. Even so, I believe that anonymously accessible objects will *always* be logged as Anonymous.
--
Paul Winkler http://www.slinkp.com Look! Up in the sky! It's PYRO BOAT LIUTENANT! (random hero from isometric.spaceninja.com)
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
-- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's LECTRO HYDROXY BITCH! (random hero from isometric.spaceninja.com)
Thanks loads for your answers, Thankfully yesterday I found Paul's "shameful fix" as mentioned by Dennis... I merged it into my code and it's now working beautifully .... Cheers Ruth ----- Original Message ----- From: "Dennis Allison" <allison@sumeru.stanford.edu> To: "Paul Winkler" <pw_lists@slinkp.com> Cc: <zope@zope.org> Sent: Thursday, October 16, 2003 10:21 PM Subject: Re: [Zope] Re: Z2.log logs user as Anonymous
I had the same problem which was solved by pault. i have patched the version of ZServer I use to handle the logs properly. Here's Paul's "shameful fix". It works for Zope 2.5.1 through 2.6.2b3.
Subject: Re: Z2.log user name problem From: Paul Tiemann <pault@center7.com> To: Dennis Allison <allison@sumeru.stanford.EDU> Cc: zope@zope.org
I'm using out-of-the-box user authentication with CookieCrumbler. Everything seems fine except that the identified user in the Z2.log file is wrong.
I've got a "fix" for your problem. It wouldn't have been my first choice to do it the way I did, but it works, and it's quicker than my other options were...
(Some history) I had the same problem with cookie-based authentication. The root of the problem lies in the log() method of the file ZServer/medusa/http_server.py. That method uses the 'Authorization' header of the request to determine the name of the user. Due to the architecture of the internal objects used to represent the request at this level (not the "REQUEST" we're usually used to using, but another lower-level request object) the 'Authorization' header is a read-only field. I believe it's the __get_item__ and __set_item__ methods that are custom for that request object, so that all attempts to "set" the Authorization HTTP header will just be dumped into the list of response headers. Since I could see no other way to get around the problem by making a change in the 'CookieCrumbler', or in my case 'LDAPUserFolder' products, I decided to just fix the problem by monkey-patching the log() method in the http_server.py file itself.
To do that, you can do something like this:
1) Add two lines like these to the top of http_server.py for the import you'll need below to make parsing the cookies easier.
# PAUL DID THIS SHAMEFUL THING from ZPublisher.HTTPRequest import parse_cookie
2) Down near line 290, you have the part that determines the name that will go to the Z2.log file. Here, you see 'name' being set to 'Anonymous', then there is an 'if auth is not None:' block which determines the name from the "Authorization" header. In my case, I added an 'else:' block below the if which has this dirty patch of code:
try: auth_cookie_name = "my_auth" # probably '__ac'? cookie = None try: cookies = {} header_value = self.get_header("Cookie") if header_value: parse_cookie(header_value, cookies) cookie = cookies.get(auth_cookie_name, None) except: name = "Anonymous"
if cookie is not None: cookie = unquote( cookie ) try: cookie = base64.decodestring( cookie ) name, password = tuple( cookie.split( ':', 1 ) ) except: name = "Unknown (bad auth cookie)" except: name = "Failure!"
Note that the way I solved the problem is "brittle" because should you ever change your auth_cookie_name, and forget to change it in http_server.py as well, you'll stop seeing correct values in your logs.
One more important note: Since you have more than one acl_users, you might want to put the 'Cookie' based name-fetch code before the 'Authorization' header based stuff. It would be possible for you to log in as admin, then use the cookie-based login page to authenticate as a normal user, in which case your browser will be sending the 'Authorization' header, as well as the cookie, and that would cause the standard acl_users username to be logged...
I assume there is some method which needs to be called to update the username for logging purposes when the login is upgraded, but I've been unable to find it. Or is this a problem caused by the lack of a CookieCrumbler in the root folder....
I tried to find a method like the one you're describing, and one alternative to my solution would have been to add that kind of facility to the low-level request object, and make different changes to http_server.py so it would get the user's name from that new variable instead of from the Authorization header, but I couldn't find it, and it didn't appear that CookieCrumbler was doing that either...
If there is an alternative solution that is more desirable than my own, I would love to hear about it... Maybe someone on the list knows another way...
Good luck, I hope I've helped, ;) Paul
On Thu, 16 Oct 2003, Paul Winkler wrote:
On Thu, Oct 16, 2003 at 07:23:24PM +0200, Jochen Knuth wrote:
the problem here is the use of cookie based authentication. so the
user
info is not in the http authentication header, which is where the user in the logs come from. So you have the choice:
1. user names in the logs -> dont use cookie base authentication 2. cookie based authentication (login with forms) - >no user names in logs
That may be, I don't use cookie auth much. Even so, I believe that anonymously accessible objects will *always* be logged as Anonymous.
--
Paul Winkler http://www.slinkp.com Look! Up in the sky! It's PYRO BOAT LIUTENANT! (random hero from isometric.spaceninja.com)
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
_______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
participants (4)
-
Dennis Allison -
Jochen Knuth -
Paul Winkler -
Ruth Mizzi