Re: [Zope-dev] REQUEST.AUTHENTICATED_USER question
--On Thursday, January 24, 2002 01:35:56 AM -0500 vio <[EMAIL PROTECTED]> 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 ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] REQUEST.AUTHENTICATED_USER question
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 <[EMAIL PROTECTED]> [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 >> >> ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] REQUEST.AUTHENTICATED_USER question
Excellent! Precisely what I'm looking for. Thanks! Vio * Jens Vagelpohl <[EMAIL PROTECTED]> [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 > > ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] REQUEST.AUTHENTICATED_USER question
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 <[EMAIL PROTECTED]> [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 - [EMAIL PROTECTED] > 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 ) ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] REQUEST.AUTHENTICATED_USER question
* Leonardo Rochael Almeida <[EMAIL PROTECTED]> [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 - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] REQUEST.AUTHENTICATED_USER question
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:
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 <[EMAIL PROTECTED]> [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'.
>
> get the beef
>
> 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 t
Re: [Zope-dev] REQUEST.AUTHENTICATED_USER question
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'.
>
> get the beef
>
> 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 co
Re: [Zope-dev] REQUEST.AUTHENTICATED_USER question
First, thanks for your time on this thread, everybody!
* Leonardo Rochael Almeida <[EMAIL PROTECTED]> [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'.
get the beef
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
Re: [Zope-dev] REQUEST.AUTHENTICATED_USER question
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. ___ Zope-Dev maillist - [EMAIL PROTECTED] 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 )
Re: [Zope-dev] REQUEST.AUTHENTICATED_USER question
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
("[EMAIL PROTECTED]" 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 , [EMAIL PROTECTED] 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 <[EMAIL PROTECTED]> [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 - [EMAIL PROTECTED]
> http://lists.zope.org/mailman/listinfo/zope-dev
> ** No cross posts or HTML encoding! **
> (Related lists -
> htt
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 <[EMAIL PROTECTED]> [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 - [EMAIL PROTECTED]
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 )
Re: [Zope-dev] REQUEST.AUTHENTICATED_USER question
the user gets modified automatically, provided you use common login-methodology and a user folder that supports it. you don't set the user "manually". 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 - [EMAIL PROTECTED] 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 )
[Zope-dev] REQUEST.AUTHENTICATED_USER question
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 - [EMAIL PROTECTED] 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 )
