Hi Uwe, If possible, continue to cc the Zope list on this... thanks... You can explicitly cause a transaction to be committed, but not in DTML or in a Python Script. You'll need to use an external method... Here's an example of an function which does this: def commit_trans(): get_transaction().commit() Make an external method named commit_trans, reference this function from within the external method UI, and then from dtml, you can do this: <dtml-call commit_trans> ... right before the raise. This should save the session data, then it won't matter if you raise afterwards in the DTML. HTH, - C ----- Original Message ----- From: "Uwe C. Schroeder" <Uwe.Schroeder@contrada.de> To: "Chris McDonough" <chrism@digicool.com> Sent: Monday, April 16, 2001 2:32 PM Subject: Re: CoreSessionTracking -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 16 April 2001 20:22, you wrote:
Hi Uwe,
Thanks for the concise explanation of the problem... I'm cc'ing the Zope list on this... it's best to keep this stuff on the Zope list because the message archive helps other folks out (including me! ;-)
I think what's happening here is that the dtml-raise in the middle of the first snippet of DTML below aborts the ZODB transaction, and so the session data is never saved...
Is there a way to prompt for authorization without doing a DTML raise? I've never used LoginManager...
Hi, wow - that's a quick answer. No I don't think that there's another way to do handle loginmanager. Loginmanager gets called on an authorization exception. The LoginForm isn't called directly, but gets called on any object a user tries to view without proper authentication. I don't know much about ZODB transactions, but probably you know if there's a way to finish the old transaction and start a new one ? Thanks - I'll try to remove the raise. Regards Uwe C. Schröder - -- Uwe C. Schröder ConTrada Consultants Lindenstrasse 15 Tel/Fax: +49 8294 80070 D-86477 Adelsried Mobil: +49 172 8532352 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE62zrRTJbO78VG0aIRAhVvAKCq1jMYJgKai9x4qBLCKS1y8rAigACffDfG IqFwZQA8KO4a6d5++Qpik/o= =IV1E -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 16 April 2001 20:47, Chris McDonough wrote:
Hi Uwe,
If possible, continue to cc the Zope list on this... thanks...
No problem.
You can explicitly cause a transaction to be committed, but not in DTML or in a Python Script. You'll need to use an external method...
Here's an example of an function which does this:
def commit_trans(): get_transaction().commit()
Make an external method named commit_trans, reference this function from within the external method UI, and then from dtml, you can do this:
<dtml-call commit_trans>
.... right before the raise. This should save the session data, then it won't matter if you raise afterwards in the DTML.
Ok, I did this - no effect. But I tried to use a normal dtml-method with the form on it and the same session related code. That works. So it isn't a general problem of my installation or the session management. It must have something to do with the login manager stuff. I'll dig into login manager and see how things work there. I think the guess about the raise might be quite good. When I remove the raise from the login manager method the method won't get called at all - instead the normal "basic auth" window appears. So my bet is that there is another raise with something like "auth required" inside the login manager methods. I'll check that. Probably only the placement of the commit is wrong. Thanks for your help
HTH,
- C
----- Original Message ----- From: "Uwe C. Schroeder" <Uwe.Schroeder@contrada.de> To: "Chris McDonough" <chrism@digicool.com> Sent: Monday, April 16, 2001 2:32 PM Subject: Re: CoreSessionTracking
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday 16 April 2001 20:22, you wrote:
Hi Uwe,
Thanks for the concise explanation of the problem... I'm cc'ing the Zope list on this... it's best to keep this stuff on the Zope list because the message archive helps other folks out (including me! ;-)
I think what's happening here is that the dtml-raise in the middle of the first snippet of DTML below aborts the ZODB transaction, and so the
session
data is never saved...
Is there a way to prompt for authorization without doing a DTML raise? I've never used LoginManager...
Hi,
wow - that's a quick answer. No I don't think that there's another way to do handle loginmanager. Loginmanager gets called on an authorization exception. The LoginForm isn't called directly, but gets called on any object a user tries to view without proper authentication. I don't know much about ZODB transactions, but probably you know if there's a way to finish the old transaction and start a new one ?
Thanks - I'll try to remove the raise.
Regards
Uwe C. Schröder
- -- Uwe C. Schröder ConTrada Consultants Lindenstrasse 15 Tel/Fax: +49 8294 80070 D-86477 Adelsried Mobil: +49 172 8532352 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org
iD8DBQE62zrRTJbO78VG0aIRAhVvAKCq1jMYJgKai9x4qBLCKS1y8rAigACffDfG IqFwZQA8KO4a6d5++Qpik/o= =IV1E -----END PGP SIGNATURE-----
- -- Uwe C. Schröder - -- Uwe C. Schröder ConTrada Consultants Lindenstrasse 15 Tel/Fax: +49 8294 80070 D-86477 Adelsried Mobil: +49 172 8532352 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE624xuTJbO78VG0aIRAkffAKCcq1vvEhFDBEYGJzUtRCiwr86CKACgkd/u Sg+6FrhZRZjT8UVUo+LN5zc= =+pAI -----END PGP SIGNATURE-----
Uwe, I misunderstood the context in which you were using the dtml method. I thought it was a dtml method which was outside of a LoginManager instance but which called a LoginManager instance somehow. Sorry.
From your latest description, it seems that my transaction theory might be wrong. It wouldn't really matter if the raise happened later. As long as the commit happens directly after the set, the session data should show up in any subsequent access. Zope has implicit transaction boundaries where the beginning of a request starts a ZODB transaction and the beginning of a response commits it. Explicitly committing a transaction like this just causes the ZODB to begin a new transaction during the processing of the request, so this is the series of events that probably happens when you use the dtml form with the commit_trans thingy in it:
request starts transaction 1 begins session data is set transaction 1 is committed (session data is stored) transaction 2 begins dtml-raise happens transaction 2 is aborted due to the raise response is sent I'm not completely sure of this because I don't know how loginmanager treats a "raise LoginRequired", but if it treats it anything like Zope treats "raise Unauthorized", it means that stuff done in the transaction immediately prior to the raise is lost, and a new transaction starts. Let me try to understand this better (and sorry if these sound like dumb questions). You want an unauthorized exception to be caught by something that examines the session data and determines if there's a key/value pair in the session data object that matches something. If so, let the user in. If not, cause a web form to be shown asking for authentication. What value is in the request that you're trying to compare against the session data to do authentication? A cookie value? - C "Uwe C. Schroeder" wrote:
Ok, I did this - no effect. But I tried to use a normal dtml-method with the form on it and the same session related code. That works. So it isn't a general problem of my installation or the session management. It must have something to do with the login manager stuff. I'll dig into login manager and see how things work there. I think the guess about the raise might be quite good. When I remove the raise from the login manager method the method won't get called at all - instead the normal "basic auth" window appears. So my bet is that there is another raise with something like "auth required" inside the login manager methods. I'll check that. Probably only the placement of the commit is wrong.
Thanks for your help
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 17 April 2001 04:28, Chris McDonough wrote: Chris, If you like we can go on with this on the list only. I subscribed the list meanwhile. ok, to clarify things I try to explain what I really want to do. I have a Zope site running which has to areas of access. One for the general public and one for authenticated users. The site is for a pharmaceutical company and german law prohibits the publication of information about prescription medicine to the general public. Such information may only be provided for doctors, nurses etc. The customer has a database with logins (from the old server we are going to replace). For that part I use loginmanager with skin scripts to authenticate the "old" users against the sql database. That works perfectly. There is a second way to authenticate. In germany there is a company called dokcheck.de, they provide authentication services for medical staff. So you only have to have one account at dokcheck and can enter nearly every pharmaceutical site. So it's similar to adultcheck.com or other auth services like. My primary idea was to use login manager features to try a login request against several user sources (thats what login manager can do) and I thought of a source like "generate a request at dokcheck.de, get an answer and let them in". But this company won't allow the contents of the login form go to my server. In technical terms: the action of the form is a www.dokcheck.de URL . After successful auth they redirect the users browser back to my server and append any "hidden" form contents to the URL (get method). So my thought was to generate a session token and send this token along to the auth server. I'll get it back when they redirect the client back to me and I can authenticate the client. This won't be very secure, but that's no problem since german law says nothing about weak authentication for this concern :-) Currently the customer has a known user/password combination which is printed on published marketing material. So security really isn't an issue. I'm just testing this second thought. In short terms: If auth is requested (loginmanager) 1) generate a token 2) remeber the path of the page where the client wanted to go 3) create the login form with the session token as hidden and target at dokcheck 4) "listen" to any request from a browser where a session token is sent. 5) check the session token if there is a path information available 6) if so give 'em the right page, if not got to 1) I wrote a little perl script that simaulates the remote auth service: #!/usr/bin/perl use CGI qw/:all/; $user=param(-name=>'ac_name'); $pass=param(-name=>'ac_password'); %pars=CGI::Vars(); $np=undef; foreach $i (keys(%pars)) { if($i ne 'ac_name' and $i ne 'ac_password') { $np.="&$i=".param($i) } } if($pass eq "bla") { $mp='?type=A'.$np; print redirect(-uri=>"http://tiburon.i.contrada.de:8080/Beta/B_Fachkreise/DocCheckHandler".$mp); } This will redirect to the given URL with all form fields appended if the password is "bla". The "type=A" parameter is something they will send to tell me if the client is a doctor or a nurse or whatever medical staff. One could provide different contents on that. I don't really authenticate the user. I rely on the info that is handed to the auth service and is sent back to me via browser redirect. Hope that clarifies things a little.
Uwe,
I misunderstood the context in which you were using the dtml method. I thought it was a dtml method which was outside of a LoginManager instance but which called a LoginManager instance somehow. Sorry.
From your latest description, it seems that my transaction theory might
be wrong. It wouldn't really matter if the raise happened later. As long as the commit happens directly after the set, the session data should show up in any subsequent access. Zope has implicit transaction boundaries where the beginning of a request starts a ZODB transaction and the beginning of a response commits it. Explicitly committing a transaction like this just causes the ZODB to begin a new transaction during the processing of the request, so this is the series of events that probably happens when you use the dtml form with the commit_trans thingy in it:
request starts transaction 1 begins session data is set transaction 1 is committed (session data is stored) transaction 2 begins dtml-raise happens transaction 2 is aborted due to the raise response is sent
I'm not completely sure of this because I don't know how loginmanager treats a "raise LoginRequired", but if it treats it anything like Zope treats "raise Unauthorized", it means that stuff done in the transaction immediately prior to the raise is lost, and a new transaction starts.
Let me try to understand this better (and sorry if these sound like dumb questions). You want an unauthorized exception to be caught by something that examines the session data and determines if there's a key/value pair in the session data object that matches something. If so, let the user in. If not, cause a web form to be shown asking for authentication. What value is in the request that you're trying to compare against the session data to do authentication? A cookie value?
- C
"Uwe C. Schroeder" wrote:
Ok, I did this - no effect. But I tried to use a normal dtml-method with the form on it and the same session related code. That works. So it isn't a general problem of my installation or the session management. It must have something to do with the login manager stuff. I'll dig into login manager and see how things work there. I think the guess about the raise might be quite good. When I remove the raise from the login manager method the method won't get called at all - instead the normal "basic auth" window appears. So my bet is that there is another raise with something like "auth required" inside the login manager methods. I'll check that. Probably only the placement of the commit is wrong.
Thanks for your help
- -- Uwe C. Schr�der - -- Uwe C. Schr�der ConTrada Consultants Lindenstrasse 15 Tel/Fax: +49 8294 80070 D-86477 Adelsried Mobil: +49 172 8532352 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE63AI+TJbO78VG0aIRArhRAJ9lk6aB7/pvtlVvJQY1wZLp6jmFvwCgplNj WpqZdnryyGTSN1Ex9lTRSJg= =sjBs -----END PGP SIGNATURE-----
"Uwe C. Schroeder" wrote:
Chris,
If you like we can go on with this on the list only. I subscribed the list meanwhile.
I'd like the conversation be preserved in the mail list archives so that other folks wanting to do a similar thing can find it.
Currently the customer has a known user/password combination which is printed on published marketing material. So security really isn't an issue. I'm just testing this second thought. In short terms: If auth is requested (loginmanager) 1) generate a token 2) remeber the path of the page where the client wanted to go 3) create the login form with the session token as hidden and target at dokcheck 4) "listen" to any request from a browser where a session token is sent. 5) check the session token if there is a path information available 6) if so give 'em the right page, if not got to 1)
Possible idea: instead of using a session here, would it be possible to embed a hidden form field in the form that posts to dokcheck like: <input type="hidden" name="backto" value="<dtml-var "REQUEST['PATH_INFO']">"> Then when the dokcheck server's redirect happens, your DocCheckHandler can redirect (again!) to the right page based on the "backto" value. Or it can just render the object referred to by "backto" without doing a redirect by doing something like (untested): <dtml-if <<user is authenticated>> > <dtml-return "restrictedTraverse(REQUEST['backto'])"> </dtml-if> Note: lots of folks consider dtml-return to be evil and consider a redirect to be the preferred way of doing this.
I wrote a little perl script that simaulates the remote auth service: #!/usr/bin/perl
use CGI qw/:all/; $user=param(-name=>'ac_name'); $pass=param(-name=>'ac_password'); %pars=CGI::Vars(); $np=undef; foreach $i (keys(%pars)) { if($i ne 'ac_name' and $i ne 'ac_password') { $np.="&$i=".param($i) } } if($pass eq "bla") { $mp='?type=A'.$np; print redirect(-uri=>"http://tiburon.i.contrada.de:8080/Beta/B_Fachkreise/DocCheckHandler".$mp); }
I understand.
This will redirect to the given URL with all form fields appended if the password is "bla". The "type=A" parameter is something they will send to tell me if the client is a doctor or a nurse or whatever medical staff. One could provide different contents on that.
If I visit your DocCheckHandler method, eg. http://tiburon.i.contrada.de:8080/Beta/B_Fachkreise/DocCheckHandler?type=A&_... Do you check the HTTP_REFERER here to make sure that dokcheck was the referer? It's almost pointless, I guess, but it's probably the right thing to do.
I don't really authenticate the user. I rely on the info that is handed to the auth service and is sent back to me via browser redirect.
Hope that clarifies things a little.
It does, many thanks. I think from what you wrote that you aren't allowed to go authenticate the user on behalf of his browser by using httplib on the server to talk to dokcheck directly. But this is probably what I would try to do if I were able to -- I'd try my hardest to use dokcheck like any other authentication data repository and let the server proxy for the client by writing a method that visits the dokcheck server with auth data that ultimately returns the boolean 1 or 0 for authentication good or authentication bad instead of actually redirecting the client to the dokcheck login page. This would obviously let you subvert the problem of maintaining state across client requests (because there would be only one). You could get fancy after that and cache auth info by putting an "already authenticated" flag into the session data object associated with the client in order to speed things up for subsequent client requests (although it's completely insecure and dangerous). Since that's probably not an option for you, I downloaded and installed LoginManager to test out what you're trying to do. Unfortunately, I'm utterly baffled by the interface and I don't have enough time to cull the unformation out of howtos or the help system. If you can work with me in giving me enough information by way of sharing your user source files and login methods, maybe I can try to reproduce the problem here.. maybe I'll learn something about loginmanager in the process. - C
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Monday 16 April 2001 20:47, Chris McDonough wrote: Hi Chris, the commit doesn't work as expected. My bet it that SessionTracking won't save any sessiondata in a auth method. I traced through loginmanager - but there are no exceptions in the code (none relevant). The general architecture leads me to the asumption that the exception must be generated in the Zope core. I did something else: I use the SessionID to store values in a SQL database. That works. So it really has something to do with the storage. For now I use the SQL solution - since the project needs a database anyways thats no big impact. But it would have been nice to use the CoreSessionTracking - methods, since they're more flexible. Lucky me that the site has no big traffic - SQL slows things down. Thanks for you help.
Hi Uwe,
If possible, continue to cc the Zope list on this... thanks...
You can explicitly cause a transaction to be committed, but not in DTML or in a Python Script. You'll need to use an external method...
Here's an example of an function which does this:
def commit_trans(): get_transaction().commit()
Make an external method named commit_trans, reference this function from within the external method UI, and then from dtml, you can do this:
<dtml-call commit_trans>
.... right before the raise. This should save the session data, then it won't matter if you raise afterwards in the DTML.
HTH,
- C
----- Original Message ----- From: "Uwe C. Schroeder" <Uwe.Schroeder@contrada.de> To: "Chris McDonough" <chrism@digicool.com> Sent: Monday, April 16, 2001 2:32 PM Subject: Re: CoreSessionTracking
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Monday 16 April 2001 20:22, you wrote:
Hi Uwe,
Thanks for the concise explanation of the problem... I'm cc'ing the Zope list on this... it's best to keep this stuff on the Zope list because the message archive helps other folks out (including me! ;-)
I think what's happening here is that the dtml-raise in the middle of the first snippet of DTML below aborts the ZODB transaction, and so the
session
data is never saved...
Is there a way to prompt for authorization without doing a DTML raise? I've never used LoginManager...
Hi,
wow - that's a quick answer. No I don't think that there's another way to do handle loginmanager. Loginmanager gets called on an authorization exception. The LoginForm isn't called directly, but gets called on any object a user tries to view without proper authentication. I don't know much about ZODB transactions, but probably you know if there's a way to finish the old transaction and start a new one ?
Thanks - I'll try to remove the raise.
Regards
Uwe C. Schröder
- -- Uwe C. Schröder ConTrada Consultants Lindenstrasse 15 Tel/Fax: +49 8294 80070 D-86477 Adelsried Mobil: +49 172 8532352 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org
iD8DBQE62zrRTJbO78VG0aIRAhVvAKCq1jMYJgKai9x4qBLCKS1y8rAigACffDfG IqFwZQA8KO4a6d5++Qpik/o= =IV1E -----END PGP SIGNATURE-----
- -- Uwe C. Schröder - -- Uwe C. Schröder ConTrada Consultants Lindenstrasse 15 Tel/Fax: +49 8294 80070 D-86477 Adelsried Mobil: +49 172 8532352 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.4 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE638y9TJbO78VG0aIRAp4+AJ9QN7PHcy4ukph+gUNetSOlVk+DEgCdHHKd tqugd0ZtS5XG0oNoDTy6ASY= =mBWe -----END PGP SIGNATURE-----
participants (2)
-
Chris McDonough -
Uwe C. Schroeder