struggeling with a sessionbased LoginMethod
Hi, I trying to develop a LoginMethod with the LoginManager product, which does not use the HTTP-authentication at all. But stores the user-information in a session, I am using CoreSessionTracking 0.9. If I call the loginForm directly, the user can login and can work in his session. He can logout and login again, everthing seams to work as exspected. the structure is like this: acl_users (default) AppFolder (not protected) acl_users (LoginManager) head foot index_html: <dtml-var head> <dtml-var content> <dtml-var foot> testFolder (protected) content When I now - as anonymous - call AppFolder/testFolder/content directly, which is not accessible to anonymous, the LoginManager-loginform pops up. But when I access AppFolder/testFolder, the default http-authorisation box pops up. When I test this with ZDebug, I get the information, that Zope is trying to publish index_html, and that user Anonymous is not allowed to access content. I debugged this, with the python-debugger and found, that only for the index_html, it is calling the validate-function of the LoginManager-acl_users. There the response.unauthorized is set to the correct loginForm. But further on the validate-functions of User.py are called. I posted this problem to the zpatterns-list, and got the following answer: Begin citation ------------------- Date: Tue, 6 Nov 2001 15:12:27 -0800 From: John Eikenberry <jae-zpat@kavi.com> To: zpatterns <zpatterns@eby-sarna.com> Subject: Re: [ZPatterns] still struggeling with a sessionbased LoginMethod I ran into the same problem. Turns out that Zope has 2 security mechanisms. The first checks the permissions on the published objects. The second is used when doing things like parsing the dtml. There is no way around it besides making sure that every folder that restricts access has an index_html in it. The index_html is looked for at publishing time and will trigger the loginForm. We had to go back to basic auth as we had just finished developing a whole publishing setup that was built around the idea of having 1 index_html at the top level. :P End citation ------------------- Can someone with the real Zope-Zen help ? Mit freundlichen Grüßen Joachim Schmitz AixtraWare, Ing. Büro für Internetanwendungen Hüsgenstr. 33a, D-52457 Aldenhoven Telefon: +49-2464-8851, FAX: +49-2464-905163
Joachim - I can't help you with LoginManager, but I did build a customized version of the acl_users folder that is tightly integrated with core session tracking. You might want to consider using it or simply to duplicate the same behavior. Please see the e-mail below. regards, - joe n At Mon, 29 Oct 2001 15:35:03 +0900, norton wrote:
I have updated the tarball for CoreSessionUserFolder product (version 0.0.3) on the zope.org website. You can access the tarball from my home page at:
http://www.zope.org/Members/natsukashi/index.html
I have changed the implementation slightly and refined the usage model. The basic idea is that an anonymous session object is automatically converted into a zope user object given some trigger criteria. After conversion to a zope user object, the anonymous web user is granted access via zope's security machinery to some protected resource (like index_html). The session user/object will then be automatically deleted unless the session's life is extended by another trigger criteria. By using CookieCrumbler in conjunction with CoreSessionUserFolder, all of the login/logout mechanisms are nicely hidden from the anonymous user.
I have also included a small demo *.zexp (install/README.txt) that can be used out-of-the-box once all of the necessary patches (patches.README.txt) have been applied. It requires zope 2.4.*, CST 0.0.9, and the cookie crumbler product.
I have labeled it a prototype simply because it has not been reviewed yet outside of our organization. Unless there are any troubles, this product will be in production usage tomorrow. You can access the website (a fortune telling site) given the following url:
http://www.unkei.com/unkei/menu.html
A CoreSessionUserFolder backs each of the content menus and implements a pay-per-view service where a credit card purchase acts as the session extending trigger. Unfortunately, the content is only in Japanese and a payment using a major credit card is required to view the content.
Obviously, any feedback good or bad are appreciated.
- joe n.
This is cool. I wish I'd had the chance to review it so far so I might be able to roll some of the changes into CST. Sorry Joseph. :-( ----- Original Message ----- From: "Joseph Wayne Norton" <norton@alum.mit.edu> To: "Joachim Schmitz" <js@aixtraware.de> Cc: <zope-dev@zope.org> Sent: Wednesday, November 07, 2001 9:41 AM Subject: Re: [Zope-dev] struggeling with a sessionbased LoginMethod
Joachim -
I can't help you with LoginManager, but I did build a customized version of the acl_users folder that is tightly integrated with core session tracking. You might want to consider using it or simply to duplicate the same behavior. Please see the e-mail below.
regards,
- joe n
At Mon, 29 Oct 2001 15:35:03 +0900, norton wrote:
I have updated the tarball for CoreSessionUserFolder product
(version
0.0.3) on the zope.org website. You can access the tarball from my home page at:
http://www.zope.org/Members/natsukashi/index.html
I have changed the implementation slightly and refined the usage model. The basic idea is that an anonymous session object is automatically converted into a zope user object given some trigger criteria. After conversion to a zope user object, the anonymous web user is granted access via zope's security machinery to some protected resource (like index_html). The session user/object will then be automatically deleted unless the session's life is extended by another trigger criteria. By using CookieCrumbler in conjunction with CoreSessionUserFolder, all of the login/logout mechanisms are nicely hidden from the anonymous user.
I have also included a small demo *.zexp (install/README.txt) that can be used out-of-the-box once all of the necessary patches (patches.README.txt) have been applied. It requires zope 2.4.*, CST 0.0.9, and the cookie crumbler product.
I have labeled it a prototype simply because it has not been reviewed yet outside of our organization. Unless there are any troubles, this product will be in production usage tomorrow. You can access the website (a fortune telling site) given the following url:
http://www.unkei.com/unkei/menu.html
A CoreSessionUserFolder backs each of the content menus and implements a pay-per-view service where a credit card purchase acts as the session extending trigger. Unfortunately, the content is only in Japanese and a payment using a major credit card is required to view the content.
Obviously, any feedback good or bad are appreciated.
- joe n.
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://lists.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://lists.zope.org/mailman/listinfo/zope-announce http://lists.zope.org/mailman/listinfo/zope )
Joachim Schmitz writes:
I trying to develop a LoginMethod with the LoginManager product, which does not use the HTTP-authentication at all. But stores the user-information in a session, I am using CoreSessionTracking 0.9.
If I call the loginForm directly, the user can login and can work in his session. He can logout and login again, everthing seams to work as exspected.
the structure is like this:
acl_users (default) AppFolder (not protected) acl_users (LoginManager) head foot index_html: <dtml-var head> <dtml-var content> <dtml-var foot> testFolder (protected) content
When I now - as anonymous - call AppFolder/testFolder/content directly, which is not accessible to anonymous, the LoginManager-loginform pops up. Is it possible that there is an object named "content" above the AppFolder?
In this case, a LoginManager authorized user would not be able to access it, unless it can be accessed by Anonymous. Dieter
On Wed, 7 Nov 2001, Dieter Maurer wrote:
Joachim Schmitz writes:
I trying to develop a LoginMethod with the LoginManager product, which does not use the HTTP-authentication at all. But stores the user-information in a session, I am using CoreSessionTracking 0.9.
If I call the loginForm directly, the user can login and can work in his session. He can logout and login again, everthing seams to work as exspected.
the structure is like this:
acl_users (default) AppFolder (not protected) acl_users (LoginManager) head foot index_html: <dtml-var head> <dtml-var content> <dtml-var foot> testFolder (protected) content
When I now - as anonymous - call AppFolder/testFolder/content directly, which is not accessible to anonymous, the LoginManager-loginform pops up. Is it possible that there is an object named "content" above the AppFolder?
In this case, a LoginManager authorized user would not be able to access it, unless it can be accessed by Anonymous.
No all objects accessed by index_html are on the same or a lower level. Mit freundlichen Grüßen Joachim Schmitz AixtraWare, Ing. Büro für Internetanwendungen Hüsgenstr. 33a, D-52457 Aldenhoven Telefon: +49-2464-8851, FAX: +49-2464-905163
participants (4)
-
Chris McDonough -
Dieter Maurer -
Joachim Schmitz -
Joseph Wayne Norton