Re: [Zope-dev] REQUEST.AUTHENTICATED_USER question
The point in a customised login method is precisely to do just that: validate user credentials with some custom scheme. If interested, this is trivial to do with a valid UserFolder instance around: 'if my_custon_loginForm_password == Users_folder.getUser(my_custon_loginForm_loginName)._getPassword(): and here SWITCH to the authenticated new user identity'.And Voila! No sweat. But I just don't know nor understand how to do that switch yet, 'programmatically'. * Jens Vagelpohl <jens@zope.com> [020121 09:02]:
the user gets modified automatically, provided you use common login-methodology and a user folder that supports it.
You must be referring to the routine HTTPResponse.HTTPResponse.unauthorised(), called with REQUEST.RESPONSE.unauthorised(). It just happens that I really don't like that 'Basic Authentication' dialog, that's why I want to use mine. So I've done half of the job to that end, only remaining problem is to switch 'programmatically' to the new authenticated user id. Doing something like 'REQUEST['AUTHENTICATED_USER'] = my_custon_loginForm_loginName' seems to have no effect, because the user is still 'Anonymous User' (found with 'AUTHENTICATED_USER.getUserName()'). If only I could understand where REQUEST gets its data for its 'AUTHENTICATED_USER' attribute, I could simply change that data source, and I'd be done. But I don't still understand how REQUEST gets all the data to its attributes.
you don't set the user "manually".
Of course you do ('programmatically' not 'manually'), as proven by all the customised 'login' products out there, who are doing just that. Only the one I studied so far (CookieCrumbler) seems to re-write the REQUEST.RESPONSE at each traversal. Which to me seems like a lot of overhead. If someone could point me to where Zope keeps user state (I believe with a cookie on the user's browser, but where in the source does Zope set this cookie up?), I could simply re-write that cookie with the new User ID ... Just a thought of a simple and elegant solution (aka 'magic bullet') for my problem. Vio
jens
On Monday, January 21, 2002, at 12:35 , vio wrote:
Hi, Does anybody know what is the method call to modify the AUTHENTICATED_USER attribute? I am unable to trace where REQUEST feeds data for its AUTHENTICATED_USER attribute.
Some context to my question: I am using a custom method to authenticate users coming to my site. So when the user logs in, he is 'Anonymous User' (from call: AUTHENTICATED_USER.getUserName()). But after his login name and password checked ok, how do I switch his identity in Zope from 'Anonymous User' to his/her new identity? What I am looking for is that next time I call 'REQUEST.AUTHENTICATED_USER.getUserName()' to get the new UserName he just logged in as, not 'Anonymous User' again.
Examining CookieCrumbler.py source, this authentication product uses the 'before_publishing_traverse hook' mechanism. But isn't there a simpler way to do this than modifying REQUEST.RESPONSE at each traversal? Sounds like a lot of overhead.
Vio
the user folder does this "switch". it's not something you should do manually. by the way, since replying to your previous email to me bounced back ("blob@sympatico.ca" is unknown) i'm uncluding that here: ************** vio, i'm not sure what user folder products you were looking at, the CookieCrumbler is *not* a user folder. normal user folders do not use BeforeTraverse. look at the source for the stock user folder (lib/python/AccessControl.User.py), it is pretty much the simplest implementation around. jens On Monday, January 21, 2002, at 09:23 , blob@sympatico.ca wrote: But setting the user 'programmatically' is precisely the point of a custom login method. If I can't set the user programatically inside my code, what' s the point in a 'custom' login method then? Anyway, I know it' s feasable, because all the other 'customised' login products are doing precisely that (after each authenticating the user in their own specific way). And Zope does it in module HTTPResponse.HTTPResponse.unauthorised() (called with REQUEST['RESPONSE'].unauthorised()). But I haven't totally figured it out how that works (how Zope switches user identities ?????????). And the two 'custom UserFolder' products I've examined both seem to use ZPublisher.BeforeTraverse to 'make' this switch happen, somehow. Hence my question to this list: not 'if' the user can be switched (not 'manually' but 'programmatically'), but 'HOW'! Cheers, Vio *************** jens On Monday, January 21, 2002, at 10:32 , vio wrote:
The point in a customised login method is precisely to do just that: validate user credentials with some custom scheme. If interested, this is trivial to do with a valid UserFolder instance around: 'if my_custon_loginForm_password == Users_folder.getUser(my_custon_loginForm_loginName)._getPassword(): and here SWITCH to the authenticated new user identity'.And Voila! No sweat. But I just don't know nor understand how to do that switch yet, 'programmatically'.
* Jens Vagelpohl <jens@zope.com> [020121 09:02]:
the user gets modified automatically, provided you use common login-methodology and a user folder that supports it.
You must be referring to the routine HTTPResponse.HTTPResponse.unauthorised(), called with REQUEST.RESPONSE.unauthorised(). It just happens that I really don't like that 'Basic Authentication' dialog, that's why I want to use mine. So I've done half of the job to that end, only remaining problem is to switch 'programmatically' to the new authenticated user id. Doing something like 'REQUEST['AUTHENTICATED_USER'] = my_custon_loginForm_loginName' seems to have no effect, because the user is still 'Anonymous User' (found with 'AUTHENTICATED_USER.getUserName()'). If only I could understand where REQUEST gets its data for its 'AUTHENTICATED_USER' attribute, I could simply change that data source, and I'd be done. But I don't still understand how REQUEST gets all the data to its attributes.
you don't set the user "manually".
Of course you do ('programmatically' not 'manually'), as proven by all the customised 'login' products out there, who are doing just that. Only the one I studied so far (CookieCrumbler) seems to re-write the REQUEST.RESPONSE at each traversal. Which to me seems like a lot of overhead. If someone could point me to where Zope keeps user state (I believe with a cookie on the user's browser, but where in the source does Zope set this cookie up?), I could simply re-write that cookie with the new User ID ... Just a thought of a simple and elegant solution (aka 'magic bullet') for my problem.
Vio
jens
On Monday, January 21, 2002, at 12:35 , vio wrote:
Hi, Does anybody know what is the method call to modify the AUTHENTICATED_USER attribute? I am unable to trace where REQUEST feeds data for its AUTHENTICATED_USER attribute.
Some context to my question: I am using a custom method to authenticate users coming to my site. So when the user logs in, he is 'Anonymous User' (from call: AUTHENTICATED_USER.getUserName()). But after his login name and password checked ok, how do I switch his identity in Zope from 'Anonymous User' to his/her new identity? What I am looking for is that next time I call 'REQUEST.AUTHENTICATED_USER.getUserName()' to get the new UserName he just logged in as, not 'Anonymous User' again.
Examining CookieCrumbler.py source, this authentication product uses the 'before_publishing_traverse hook' mechanism. But isn't there a simpler way to do this than modifying REQUEST.RESPONSE at each traversal? Sounds like a lot of overhead.
Vio
_______________________________________________ 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 )
On Mon, 21 Jan 2002, vio wrote:
called with REQUEST.RESPONSE.unauthorised(). It just happens that I really don't like that 'Basic Authentication' dialog, that's why I want to use mine.
Which to me seems like a lot of overhead. If someone could point me to where Zope keeps user state (I believe with a cookie on the user's browser, but where in the source does Zope set this cookie up?), I could simply re-write that cookie with the new User ID ... Just a thought of a simple and elegant solution (aka 'magic bullet') for my problem.
Zope does not keep a user state anywhere. For Basic Auth, the browser provides the credentials on each transaction. Cookie crumbler of course uses a cookie, which again is provided with each transaction by the browser. Maybe what you should do is look at the exUserFolder product and write your own login methods (and possibly a User Source) against that. --RDM
Thanks for this information, as it provides a big puzzle into my understanding of how Zope works. As a follow-up to my initial question to this list, namely: 'how do I "login" as user X programmatically, the call seems to be something like: AccessControl.SecurityManagement.newSecurityManager(None, AccessControl.User.system) - this will log us in as 'system user' (Zope's equivalent of su). Replacing 'AccessControl.User.system' with our own string will likely log us as that user. while the 'logoff' call is: AccessControl.SecurityManagement.noSecurityManager() What I still don't understand is why this call is not permanent or 'persistent'? If I do something like the following inside a class definition: AccessControl.SecurityManagement.newSecurityManager(None, 'bozo') user1 = SecurityManagement.getSecurityManager().getUser() user2 = REQUEST.get('AUTHENTICATED_USER', None) return user1,user2 will return 'bozo',bozo'. But if I call <dtml-var "AUTHENTICATED_USER.getUserName()"> from somewhere else in my program, I still get 'Anonymous User'. Am I right in concluding that in order to make my login call 'persistent' I will have to modify the data inside the cookie which Zope hatches in my browser's nest (where Zope keeps user' state)? And that the login call AccessControl.SecurityManagement.newSecurityManager(None, 'bozo') is only valid for the duration of a single Zope transaction? Ok, I'll have a deeper look at exUserFolder, which seems much more complex than CookieCrumbler (which is why I had chosed to study CookieCrumbler in the first place). Thanks for your reply, Vio * R. David Murray <bitz@bitdance.com> [020123 12:15]:
On Mon, 21 Jan 2002, vio wrote:
called with REQUEST.RESPONSE.unauthorised(). It just happens that I really don't like that 'Basic Authentication' dialog, that's why I want to use mine.
Which to me seems like a lot of overhead. If someone could point me to where Zope keeps user state (I believe with a cookie on the user's browser, but where in the source does Zope set this cookie up?), I could simply re-write that cookie with the new User ID ... Just a thought of a simple and elegant solution (aka 'magic bullet') for my problem.
Zope does not keep a user state anywhere. For Basic Auth, the browser provides the credentials on each transaction. Cookie crumbler of course uses a cookie, which again is provided with each transaction by the browser.
Maybe what you should do is look at the exUserFolder product and write your own login methods (and possibly a User Source) against that.
--RDM
Since customizing Zope's login process seems to be so painful, an alternative would be to simply by-pass it: declare all the classes in my product who need authentication as 'Public', then implement my own security scheme over those classes ... which basically mirrors Zope's security, if not in the coding, at least in the principles and philosophy. I know, adding another security layer who basically does the same thing is not the most efficient solution, and it is more risky (bugs and security holes), but at least it does the job according to my own specifications. So guys, maybe consider making Zope's login process more customizable in a future release, so other programmers concerned with this aspect of Zope won't have to labor over understanding complex source code (Zope or 3d party), but can focus instead on more value-add tasks. Best Regards, Vio * R. David Murray <bitz@bitdance.com> [020123 12:15]:
On Mon, 21 Jan 2002, vio wrote:
called with REQUEST.RESPONSE.unauthorised(). It just happens that I really don't like that 'Basic Authentication' dialog, that's why I want to use mine.
Which to me seems like a lot of overhead. If someone could point me to where Zope keeps user state (I believe with a cookie on the user's browser, but where in the source does Zope set this cookie up?), I could simply re-write that cookie with the new User ID ... Just a thought of a simple and elegant solution (aka 'magic bullet') for my problem.
Zope does not keep a user state anywhere. For Basic Auth, the browser provides the credentials on each transaction. Cookie crumbler of course uses a cookie, which again is provided with each transaction by the browser.
Maybe what you should do is look at the exUserFolder product and write your own login methods (and possibly a User Source) against that.
--RDM
i don't quite understand the problem. there are literally dozens of user folder products that let you customize the login process in all kinds of ways. jens On Wednesday, January 23, 2002, at 02:45 , vio wrote:
Since customizing Zope's login process seems to be so painful, an alternative would be to simply by-pass it: declare all the classes in my product who need authentication as 'Public', then implement my own security scheme over those classes ... which basically mirrors Zope's security, if not in the coding, at least in the principles and philosophy. I know, adding another security layer who basically does the same thing is not the most efficient solution, and it is more risky (bugs and security holes), but at least it does the job according to my own specifications.
So guys, maybe consider making Zope's login process more customizable in a future release, so other programmers concerned with this aspect of Zope won't have to labor over understanding complex source code (Zope or 3d party), but can focus instead on more value-add tasks.
Best Regards, Vio
* R. David Murray <bitz@bitdance.com> [020123 12:15]:
On Mon, 21 Jan 2002, vio wrote:
called with REQUEST.RESPONSE.unauthorised(). It just happens that I really don't like that 'Basic Authentication' dialog, that's why I want to use mine.
Which to me seems like a lot of overhead. If someone could point me to where Zope keeps user state (I believe with a cookie on the user's browser, but where in the source does Zope set this cookie up?), I could simply re-write that cookie with the new User ID ... Just a thought of a simple and elegant solution (aka 'magic bullet') for my problem.
Zope does not keep a user state anywhere. For Basic Auth, the browser provides the credentials on each transaction. Cookie crumbler of course uses a cookie, which again is provided with each transaction by the browser.
Maybe what you should do is look at the exUserFolder product and write your own login methods (and possibly a User Source) against that.
--RDM
_______________________________________________ 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 )
* Jens Vagelpohl <jens@zope.com> [020123 15:53]:
i don't quite understand the problem. there are literally dozens of user folder products that let you customize the login process in all kinds of ways.
Perhaps. The problem is that I can't seem to make them play nice with my own code (the few I had a look at). Surely, because I don't understand them. Also, as mentionned in a previous message in this thread, all I am looking for is for the few Zope incantations to 'switch' user identities, and I can take care of the rest. Now I found how to make this switch, using AccessControl.SecurityManagement.newSecurityManager(None, myUser) only this switch doesn't 'persist'. What is my problem then: at this point, to change the data in the cookie Zope lays on the browser, so it points to the new 'switched' user. In other words, make a 'persistent' switch. Furthermore, I don't really need an entire product to do this. Just a few well placed calls to Zope machinery seems to do the trick. Less overhead as a bonus. Cheers, Vio
well, the API calls that you are attempting to use aren't really "for public consumption". they are calls made inside the gory insides of the zope security machinery and user code shouldn't really use them. i suggest you use a cookie-enabled user folder and manipulate the cookie from your code when you want to "switch" the user. the user should be "switched" the next time a page is requested. jens On Wednesday, January 23, 2002, at 04:28 , vio wrote:
* Jens Vagelpohl <jens@zope.com> [020123 15:53]:
i don't quite understand the problem. there are literally dozens of user folder products that let you customize the login process in all kinds of ways.
Perhaps. The problem is that I can't seem to make them play nice with my own code (the few I had a look at). Surely, because I don't understand them.
Also, as mentionned in a previous message in this thread, all I am looking for is for the few Zope incantations to 'switch' user identities, and I can take care of the rest. Now I found how to make this switch, using AccessControl.SecurityManagement.newSecurityManager(None, myUser) only this switch doesn't 'persist'. What is my problem then: at this point, to change the data in the cookie Zope lays on the browser, so it points to the new 'switched' user. In other words, make a 'persistent' switch.
Furthermore, I don't really need an entire product to do this. Just a few well placed calls to Zope machinery seems to do the trick. Less overhead as a bonus.
Cheers, Vio
Hi Vio, By the contents of your message, you seem to be a little off track w.r.t. the way authentication works between the browser and Zope. By now you seem to have discovered that the browser sends the user credentials whenever it fetches a page. If you aren't using a custom user folder that uses cookies, then you're most likely using basic authentication (which is likely since you don't want the overhead of a product). To know for sure answer this question: when you are anonymous and you want to access a forbiden area, does the browser-standard-login-popup-window shows up? If yes, then there simply is no way you can use "a few placed calls to the Zope machinery" to convince the browser that it needs to switch identities because you're talking to Zope, not to the browser. Zope cannot tell the browser "stop pretending you are anonymous and start pretending you're John". The only thing Zope can tell the browser is "This user you are using is not authorized", in which case the browser will ask the user for another login/password combo, using it's own standard login popup window. On the other hand, if you are using a user-folder product (such as exUserFolder or LoginManager) and it is configured for cookie login, THEN you might be able to change the user "persistently" by changing the cookie. Note, however, that in most cases the cookie contains either a valid user/password combo or a key to a hash table that has the user/password combo. So, in order to tell the browser to pretend to be someone else, you'll probably have to provide the password that goes with the user, which will be impossible if the passwords are stored encrypted. In all cases, it will require knowledge of the format of the cookie that is exclusive to each user-folder and might change in the next version of the user-folder product. As I said, there is no way that "a few placed calls to the Zope machinery" will get what you want, but this is because it is Web, not because it is Zope. Your best bet is still trying to modify an existing, cookie-using, user-folder product, so that you can extend it to have calls that will give you the cookie that you should put in the browser to change the user identity. It's simply TOO HARD to not get involved with user-folders if what you're trying to do deals with user authentication. Cheers, Leo PS: I.M.B.O. (B. as in biased), exUserFolder is the most maleable of them all and the easiest to understand, but it is hard to understand ANY user-folder product if you don't understand Web protocols and/or Zope authentication machinery. On Wed, 2002-01-23 at 19:28, vio wrote:
[...] all I am looking for is for the few Zope incantations to 'switch' user identities, and I can take care of the rest. Now I found how to make this switch, using AccessControl.SecurityManagement.newSecurityManager(None, myUser) only this switch doesn't 'persist'. What is my problem then: at this point, to change the data in the cookie Zope lays on the browser, so it points to the new 'switched' user. In other words, make a 'persistent' switch.
Furthermore, I don't really need an entire product to do this. Just a few well placed calls to Zope machinery seems to do the trick. Less overhead as a bonus.
-- Ideas don't stay in some minds very long because they don't like solitary confinement.
First, thanks for your time on this thread, everybody! * Leonardo Rochael Almeida <leo@hiper.com.br> [020123 19:42]:
Hi Vio,
By the contents of your message, you seem to be a little off track w.r.t. the way authentication works between the browser and Zope.
By now you seem to have discovered that the browser sends the user credentials whenever it fetches a page. If you aren't using a custom user folder that uses cookies, then you're most likely using basic authentication (which is likely since you don't want the overhead of a product). To know for sure answer this question: when you are anonymous and you want to access a forbiden area, does the browser-standard-login-popup-window shows up?
yes.
If yes, then there simply is no way you can use "a few placed calls to the Zope machinery" to convince the browser that it needs to switch identities because you're talking to Zope, not to the browser. Zope cannot tell the browser "stop pretending you are anonymous and start pretending you're John". The only thing Zope can tell the browser is "This user you are using is not authorized", in which case the browser will ask the user for another login/password combo, using it's own standard login popup window.
Ok, maybe I didn't express myself very clearly in my past messages. Imagine the following simple scenario, which makes heavy use of 'CoreSessionTracking', by the way: 1. In my 'standard_html_header' I put a dtml routine who checks for a specific session variable, let's call it 'user_id'. If it isn't there, or there is no session running, it redirects user to my custom 'loginForm'. <dtml-if "sessionData.get('user_id')"> get the beef <dtml-else> redirect to loginForm 2. The manage_login() who processes the 'loginForm' data, validates user credentials against some internal list. Actually, for now I'm using a standard Users_folder object, but I am tempted to swich to something even simpler, like a dictionary or a list. I hope you follow me up to now. In that list, each user_id has also associated with it a list of roles. So here we have a central list of 'authorised' users (or a UsersFolder): clean_users.append([user_id, password, list_of_roles]) or Users_folder._addUser(name,password,confirm,roles,domains) Session-storing the credentials: manage_login() stores this related data as session variables: sessionData.set('user_id',user_id) sessionData.set('user_roles', list_of_roles) 3. Make all user-visible objects in my product 'Public', knowing that they are not 'really' public: any user without a 'user_id' session variable will get redirected to my custom login page 'no matter what'. But Zope's own security machinery is out of the loop on this one (simply by-passed). 4. The little routine in 'standard_html_header' will take care of all dtml. But I will need to call a similar validating method (or specialized instance) before running any 'executable' code: by 'executable' I mean code who Creates, Destroys, Modifies restricted objects, or modifies my custom security settings. This code simply compares content of 'user_roles' session variable with 'my_object_permissions' object attribute (which can be acquired). Only if there's a match, the 'executable' python code is allowed to run. An alternative here would have been to protect all objects with a Zope permission (instead of declaring everything public), then switch to a user with that permission for the duration of this transaction with: SecurityManagement.newSecurityManager(None, UserWithPermission) This is what I ment with "a few well placed calls to the Zope machinery". Of course I know I'm not talking to the browser, which is but a dumb client with cookies (and no milk). So it's not the browser who tells Zope "I'm doctor Zoidberg", but my own code (which acts like a proxy). In my view, this scenario implements Zope's security core 'principles' of 'Roles' matching 'Permissions', but using CoreSessionTracking. Writing this isn't as complicated as it sounds, only cumbersome to paste code into existing python classes, and edit many dtml pages to add a 'myPermissions' input field to all objects (or at least to the top objects in my hierarchy, and let those custom permissions get acquired from lower down). A full evening's work, for sure. (I think all hackers are optimists by nature) My alternative being to study and understand an existing cookie-based user-folder product, and make it play nice with my own code. Having tried the latter for the last week without satisfactory results (again, only my fault if I don't understand totally how things work), I must admit that giving a shot at the former scenario sounds quite tempting. Let's see ... But many thanks for all your help and suggestion, which has been very appreciated and useful. If you smell something rotten in my stuff here, please do let me know (besides the fact that I am trying to re-invent the wheel, of course). Cheers, Vio
On the other hand, if you are using a user-folder product (such as exUserFolder or LoginManager) and it is configured for cookie login, THEN you might be able to change the user "persistently" by changing the cookie. Note, however, that in most cases the cookie contains either a valid user/password combo or a key to a hash table that has the user/password combo. So, in order to tell the browser to pretend to be someone else, you'll probably have to provide the password that goes with the user, which will be impossible if the passwords are stored encrypted. In all cases, it will require knowledge of the format of the cookie that is exclusive to each user-folder and might change in the next version of the user-folder product.
As I said, there is no way that "a few placed calls to the Zope machinery" will get what you want, but this is because it is Web, not because it is Zope.
Your best bet is still trying to modify an existing, cookie-using, user-folder product, so that you can extend it to have calls that will give you the cookie that you should put in the browser to change the user identity. It's simply TOO HARD to not get involved with user-folders if what you're trying to do deals with user authentication.
Cheers, Leo
PS: I.M.B.O. (B. as in biased), exUserFolder is the most maleable of them all and the easiest to understand, but it is hard to understand ANY user-folder product if you don't understand Web protocols and/or Zope authentication machinery.
On Wed, 2002-01-23 at 19:28, vio wrote:
[...] all I am looking for is for the few Zope incantations to 'switch' user identities, and I can take care of the rest. Now I found how to make this switch, using AccessControl.SecurityManagement.newSecurityManager(None, myUser) only this switch doesn't 'persist'. What is my problem then: at this point, to change the data in the cookie Zope lays on the browser, so it points to the new 'switched' user. In other words, make a 'persistent' switch.
Furthermore, I don't really need an entire product to do this. Just a few well placed calls to Zope machinery seems to do the trick. Less overhead as a bonus.
-- Ideas don't stay in some minds very long because they don't like solitary confinement.
Hi vio, Pardon our insistence in helping you out, but you asked to be told if something in your description smelt rotten and, besides the fact that yes, you are reinventing the wheel (and reinventing it square, by the way :-), there isn't a single thing in the scenario you described below that isn't possible with plain vanilla Zope (ok, plain vanilla Zope is an oxymoron. There is nothing 'plain' about an out-of-the-box Zope, but I digress :-), you don't even need CoreSessionTracking as far as I understand it! What part of your description below you think you can't do in Zope? If you mean 'to change the user identity transparently throughout a certain sequence of clicks', you probably don't want it for it's own sake. If I read you correctly, you want it so that the user, while holding the new identity, has permissions it wouldn't have before (and won't have after) holding the new identity. In this case, you needn't look any further than 'Proxy Roles'. Proxy roles work sort-of like setuid in unix, in which you grant different permissions to a user that can view/run a ceirtain object/file. When you give a method one or more proxy roles, the user that can view/call it assumes these roles instead of his own. That means he has the permissions these proxy roles have, instead of the permissions his own roles would give him (which means proxy-roles can enhance as well as reduce permissions). This means proxy roles only work for that method that is being viewed/called (and other methods called from it as well), but you can give proxy roles to as many methods as you want, and you can call a proxy-roled (is that a word? :-) method from other methods and all the actions that are taken by this proxy-roled method act as if the user viewing it had the new set of roles. I'm not sure if that's what you want to achieve, but if it isn't, then pray tell us what you really wish to accomplish in the end, not just the things you think you need to do in order to achieve it. I bet there is a very simple and Zopish way of doing what you want. Maybe you are just looking at the problem under the wrong light. Regards, Leo On Thu, 2002-01-24 at 00:52, vio wrote:
[...] Imagine the following simple scenario, which makes heavy use of 'CoreSessionTracking', by the way:
1. In my 'standard_html_header' I put a dtml routine who checks for a specific session variable, let's call it 'user_id'. If it isn't there, or there is no session running, it redirects user to my custom 'loginForm'. <dtml-if "sessionData.get('user_id')"> get the beef <dtml-else> redirect to loginForm
2. The manage_login() who processes the 'loginForm' data, validates user credentials against some internal list. Actually, for now I'm using a standard Users_folder object, but I am tempted to swich to something even simpler, like a dictionary or a list. I hope you follow me up to now.
In that list, each user_id has also associated with it a list of roles. So here we have a central list of 'authorised' users (or a UsersFolder): clean_users.append([user_id, password, list_of_roles]) or Users_folder._addUser(name,password,confirm,roles,domains)
Session-storing the credentials: manage_login() stores this related data as session variables: sessionData.set('user_id',user_id) sessionData.set('user_roles', list_of_roles)
3. Make all user-visible objects in my product 'Public', knowing that they are not 'really' public: any user without a 'user_id' session variable will get redirected to my custom login page 'no matter what'. But Zope's own security machinery is out of the loop on this one (simply by-passed).
4. The little routine in 'standard_html_header' will take care of all dtml. But I will need to call a similar validating method (or specialized instance) before running any 'executable' code: by 'executable' I mean code who Creates, Destroys, Modifies restricted objects, or modifies my custom security settings. This code simply compares content of 'user_roles' session variable with 'my_object_permissions' object attribute (which can be acquired).
Only if there's a match, the 'executable' python code is allowed to run. An alternative here would have been to protect all objects with a Zope permission (instead of declaring everything public), then switch to a user with that permission for the duration of this transaction with: SecurityManagement.newSecurityManager(None, UserWithPermission)
This is what I ment with "a few well placed calls to the Zope machinery". Of course I know I'm not talking to the browser, which is but a dumb client with cookies (and no milk). So it's not the browser who tells Zope "I'm doctor Zoidberg", but my own code (which acts like a proxy).
In my view, this scenario implements Zope's security core 'principles' of 'Roles' matching 'Permissions', but using CoreSessionTracking. Writing this isn't as complicated as it sounds, only cumbersome to paste code into existing python classes, and edit many dtml pages to add a 'myPermissions' input field to all objects (or at least to the top objects in my hierarchy, and let those custom permissions get acquired from lower down). A full evening's work, for sure. (I think all hackers are optimists by nature)
My alternative being to study and understand an existing cookie-based user-folder product, and make it play nice with my own code. Having tried the latter for the last week without satisfactory results (again, only my fault if I don't understand totally how things work), I must admit that giving a shot at the former scenario sounds quite tempting. Let's see ...
But many thanks for all your help and suggestion, which has been very appreciated and useful. If you smell something rotten in my stuff here, please do let me know (besides the fact that I am trying to re-invent the wheel, of course). [...]
* Leonardo Rochael Almeida <leo@hiper.com.br> [020124 00:03]:
Hi vio,
Pardon our insistence in helping you out, but you asked to be told if something in your description smelt rotten and, besides the fact that yes, you are reinventing the wheel (and reinventing it square, by the way :-), there isn't a single thing in the scenario you described below that isn't possible with plain vanilla Zope (ok, plain vanilla Zope is an oxymoron. There is nothing 'plain' about an out-of-the-box Zope, but I digress :-), you don't even need CoreSessionTracking as far as I understand it!
First, thanks again for 'insisting' in helping me out. Really appreciate it! Ok, you asked what I really want, and it's very 'plain vanilla' stuff. In a sentence: to log users from a custom dtml page. Period. In more than one sentence: I want to 'integrate' the login process and 'user management' into my own product, give it my own product's 'look and feel', to create a consistent GUI and user experience. Idealy, I'd prefer just using plain Zope, no additional 3rd party products. But I really would prefer to present the user with a nicely customised login page instead of the standard Zope dialog. Well, that's about it. Looking for a solution here has been a great learning experience into Zope security, first of all. Now all your suggestions are pointing out towards using an existing product, 2 names flying around: LoginManager and exUserFolder. LoginManager would seem more appealing, as some comments I've read would suggest that it's very customizable. My problem with that is that Zope won't 'chew' it properly, spits it out with ImportError: can't import name 'expr_globals' in Products/ZPatterns/Expressions.py line 38. Indeed, after browsing the sources, no trace of 'expr_globals' anywhere. Deprecated? Any idea what this was replaced with (by the way, in case you're wondering, I'm running on Zope 2.4.1 with python 2.1, while on the other hand LoginManager-0-8-8b1 with ZPatterns-0-4-3b1 and PlugIns-0-4-3b1 are trying to earn a living on my hard drive). exUserFolder installed ok, so I'll give it a test drive also. But some hints on debugging LoginMgr would be also appreciated. Cheers, Vio
vio, for your situation the simplest thing would be to use the CookieUserFolder (see http://www.dataflake.org/software/cookieuserfolder) which is as simple as the standard user folder and adds cookie-capability and customizable login and logout forms. no need to get all tripped up in zpatterns or user auth sources or other confusing stuff. jens On Thursday, January 24, 2002, at 01:35 , vio wrote:
* Leonardo Rochael Almeida <leo@hiper.com.br> [020124 00:03]:
Hi vio,
Pardon our insistence in helping you out, but you asked to be told if something in your description smelt rotten and, besides the fact that yes, you are reinventing the wheel (and reinventing it square, by the way :-), there isn't a single thing in the scenario you described below that isn't possible with plain vanilla Zope (ok, plain vanilla Zope is an oxymoron. There is nothing 'plain' about an out-of-the-box Zope, but I digress :-), you don't even need CoreSessionTracking as far as I understand it!
First, thanks again for 'insisting' in helping me out. Really appreciate it! Ok, you asked what I really want, and it's very 'plain vanilla' stuff. In a sentence: to log users from a custom dtml page. Period.
In more than one sentence: I want to 'integrate' the login process and 'user management' into my own product, give it my own product's 'look and feel' , to create a consistent GUI and user experience.
Idealy, I'd prefer just using plain Zope, no additional 3rd party products. But I really would prefer to present the user with a nicely customised login page instead of the standard Zope dialog.
Well, that's about it. Looking for a solution here has been a great learning experience into Zope security, first of all. Now all your suggestions are pointing out towards using an existing product, 2 names flying around: LoginManager and exUserFolder.
LoginManager would seem more appealing, as some comments I've read would suggest that it's very customizable. My problem with that is that Zope won't 'chew' it properly, spits it out with ImportError: can't import name 'expr_globals' in Products/ZPatterns/Expressions.py line 38. Indeed, after browsing the sources, no trace of 'expr_globals' anywhere. Deprecated? Any idea what this was replaced with (by the way, in case you' re wondering, I'm running on Zope 2.4.1 with python 2.1, while on the other hand LoginManager-0-8-8b1 with ZPatterns-0-4-3b1 and PlugIns-0-4-3b1 are trying to earn a living on my hard drive).
exUserFolder installed ok, so I'll give it a test drive also. But some hints on debugging LoginMgr would be also appreciated.
Cheers, Vio
_______________________________________________ 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 )
Excellent! Precisely what I'm looking for. Thanks! Vio * Jens Vagelpohl <jens@zope.com> [020124 10:46]:
vio,
for your situation the simplest thing would be to use the CookieUserFolder (see http://www.dataflake.org/software/cookieuserfolder) which is as simple as the standard user folder and adds cookie-capability and customizable login and logout forms.
no need to get all tripped up in zpatterns or user auth sources or other confusing stuff.
jens
vio, make sure you read the README so you don't lock youself out if the login form does not have the correct input fields. jens On Thursday, January 24, 2002, at 10:55 , vio wrote:
Excellent! Precisely what I'm looking for. Thanks! Vio
* Jens Vagelpohl <jens@zope.com> [020124 10:46]:
vio,
for your situation the simplest thing would be to use the CookieUserFolder (see http://www.dataflake.org/software/cookieuserfolder) which is as simple as the standard user folder and adds cookie-capability and customizable login and logout forms.
no need to get all tripped up in zpatterns or user auth sources or other confusing stuff.
jens
--On Thursday, January 24, 2002 01:35:56 AM -0500 vio <vmilitaru@sympatico.ca> wrote:
exUserFolder installed ok, so I'll give it a test drive also. But some hints on debugging LoginMgr would be also appreciated.
Personally, I'd stay away from LoginManager. It depends on ZPatterns, a very impressive, very complex layer whose author has moved on to other things. There are a group of users supporting it to some extent with occasional help from the original authors, but I just see its future on new versions of Zope as shakier and shakier. For example, Zope 2.4 support requires using the latest CVS patches (last I looked, about a month ago). We are currently using LoginManager, but will probably convert to exUserFolder in the next month or two as part of moving our member data from ZODB to PostgreSQL. Dan Pierson
On 24 Jan 2002, Leonardo Rochael Almeida wrote:
When you give a method one or more proxy roles, the user that can view/call it assumes these roles instead of his own. That means he has the permissions these proxy roles have, instead of the permissions his own roles would give him (which means proxy-roles can enhance as well as reduce permissions). This means proxy roles only work for that method that is being viewed/called (and other methods called from it as well),
Actually, I believe this is not true. My understanding is that the proxy is only good for the method it is on. If it calls another DTML method, that sub-DTML method runs with the original user's roles. I believe the same is true for called pythonscripts. Actually, writing that down calls forth a question. If you put a proxy role on a method to *reduce* priviledges, shouldn't the reduction apply to called methods even if an increase in permissions doesn't apply to called methods? Does it? --RDM
All the user folders can be confusing, but I think in the long run, you'd be better off if you grabbed one and figured out how it worked. I've used LoginManager, and basically, I create a folder for my project, don't put the standard acl_users in it, because you want to create an object called acl_users, of type "Login Manager". There's a method in there called "userAuthenticate". When the security mechanism kicks in (on every web page hit), if this returns a 1, then all is well, if it returns a 0, then LoginManager will cause the "loginForm" method to be run, which is where you would put your custom login page. (see the loginForm method that comes with Login Manager). Here's what the userAuthenticate method would look like for your scenario: <dtml-if "REQUEST.cookies.has_key('user_id')"> <dtml-return "_.int('1')"> </dtml-if> <dtml-return "_.int('0')"> Of course that's too easy, and you'd probably want to check the username/password against stored data. I generally use a relational database... but that's another story. You can store the user data any way you like and just use these methods to validate it. You will probably also need to look at the userRoles method. The security mechanism will give you much more control over access to your objects. -Paul vio wrote:
First, thanks for your time on this thread, everybody!
* Leonardo Rochael Almeida <leo@hiper.com.br> [020123 19:42]:
Hi Vio,
By the contents of your message, you seem to be a little off track w.r.t. the way authentication works between the browser and Zope.
By now you seem to have discovered that the browser sends the user credentials whenever it fetches a page. If you aren't using a custom user folder that uses cookies, then you're most likely using basic authentication (which is likely since you don't want the overhead of a product). To know for sure answer this question: when you are anonymous and you want to access a forbiden area, does the browser-standard-login-popup-window shows up?
yes.
If yes, then there simply is no way you can use "a few placed calls to the Zope machinery" to convince the browser that it needs to switch identities because you're talking to Zope, not to the browser. Zope cannot tell the browser "stop pretending you are anonymous and start pretending you're John". The only thing Zope can tell the browser is "This user you are using is not authorized", in which case the browser will ask the user for another login/password combo, using it's own standard login popup window.
Ok, maybe I didn't express myself very clearly in my past messages. Imagine the following simple scenario, which makes heavy use of 'CoreSessionTracking', by the way:
1. In my 'standard_html_header' I put a dtml routine who checks for a specific session variable, let's call it 'user_id'. If it isn't there, or there is no session running, it redirects user to my custom 'loginForm'. <dtml-if "sessionData.get('user_id')"> get the beef <dtml-else> redirect to loginForm
2. The manage_login() who processes the 'loginForm' data, validates user credentials against some internal list. Actually, for now I'm using a standard Users_folder object, but I am tempted to swich to something even simpler, like a dictionary or a list. I hope you follow me up to now.
In that list, each user_id has also associated with it a list of roles. So here we have a central list of 'authorised' users (or a UsersFolder): clean_users.append([user_id, password, list_of_roles]) or Users_folder._addUser(name,password,confirm,roles,domains)
Session-storing the credentials: manage_login() stores this related data as session variables: sessionData.set('user_id',user_id) sessionData.set('user_roles', list_of_roles)
3. Make all user-visible objects in my product 'Public', knowing that they are not 'really' public: any user without a 'user_id' session variable will get redirected to my custom login page 'no matter what'. But Zope's own security machinery is out of the loop on this one (simply by-passed).
4. The little routine in 'standard_html_header' will take care of all dtml. But I will need to call a similar validating method (or specialized instance) before running any 'executable' code: by 'executable' I mean code who Creates, Destroys, Modifies restricted objects, or modifies my custom security settings. This code simply compares content of 'user_roles' session variable with 'my_object_permissions' object attribute (which can be acquired).
Only if there's a match, the 'executable' python code is allowed to run. An alternative here would have been to protect all objects with a Zope permission (instead of declaring everything public), then switch to a user with that permission for the duration of this transaction with: SecurityManagement.newSecurityManager(None, UserWithPermission)
This is what I ment with "a few well placed calls to the Zope machinery". Of course I know I'm not talking to the browser, which is but a dumb client with cookies (and no milk). So it's not the browser who tells Zope "I'm doctor Zoidberg", but my own code (which acts like a proxy).
In my view, this scenario implements Zope's security core 'principles' of 'Roles' matching 'Permissions', but using CoreSessionTracking. Writing this isn't as complicated as it sounds, only cumbersome to paste code into existing python classes, and edit many dtml pages to add a 'myPermissions' input field to all objects (or at least to the top objects in my hierarchy, and let those custom permissions get acquired from lower down). A full evening's work, for sure. (I think all hackers are optimists by nature)
My alternative being to study and understand an existing cookie-based user-folder product, and make it play nice with my own code. Having tried the latter for the last week without satisfactory results (again, only my fault if I don't understand totally how things work), I must admit that giving a shot at the former scenario sounds quite tempting. Let's see ...
But many thanks for all your help and suggestion, which has been very appreciated and useful. If you smell something rotten in my stuff here, please do let me know (besides the fact that I am trying to re-invent the wheel, of course). Cheers, Vio
On the other hand, if you are using a user-folder product (such as exUserFolder or LoginManager) and it is configured for cookie login, THEN you might be able to change the user "persistently" by changing the cookie. Note, however, that in most cases the cookie contains either a valid user/password combo or a key to a hash table that has the user/password combo. So, in order to tell the browser to pretend to be someone else, you'll probably have to provide the password that goes with the user, which will be impossible if the passwords are stored encrypted. In all cases, it will require knowledge of the format of the cookie that is exclusive to each user-folder and might change in the next version of the user-folder product.
As I said, there is no way that "a few placed calls to the Zope machinery" will get what you want, but this is because it is Web, not because it is Zope.
Your best bet is still trying to modify an existing, cookie-using, user-folder product, so that you can extend it to have calls that will give you the cookie that you should put in the browser to change the user identity. It's simply TOO HARD to not get involved with user-folders if what you're trying to do deals with user authentication.
Cheers, Leo
PS: I.M.B.O. (B. as in biased), exUserFolder is the most maleable of them all and the easiest to understand, but it is hard to understand ANY user-folder product if you don't understand Web protocols and/or Zope authentication machinery.
On Wed, 2002-01-23 at 19:28, vio wrote:
[...] all I am looking for is for the few Zope incantations to 'switch' user identities, and I can take care of the rest. Now I found how to make this switch, using AccessControl.SecurityManagement.newSecurityManager(None, myUser) only this switch doesn't 'persist'. What is my problem then: at this point, to change the data in the cookie Zope lays on the browser, so it points to the new 'switched' user. In other words, make a 'persistent' switch.
Furthermore, I don't really need an entire product to do this. Just a few well placed calls to Zope machinery seems to do the trick. Less overhead as a bonus.
-- Ideas don't stay in some minds very long because they don't like solitary confinement.
_______________________________________________ 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 )
participants (6)
-
Dan L. Pierson -
Jens Vagelpohl -
Leonardo Rochael Almeida -
Paul Erickson -
R. David Murray -
vio