-----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-----