[Zope] Re: CoreSessionTracking

[Uwe C. Schroeder]

-----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 lis=
t=20
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 gene=
ral=20
public and one for authenticated users. The site is for a pharmaceutical=20
company and german law prohibits the publication of information about=20
prescription medicine to the general public. Such information may only be=
=20
provided for doctors, nurses etc.
The customer has a database with logins (from the old server we are going=
 to=20
replace). For that part I use loginmanager with skin scripts to authentic=
ate=20
the "old" users against the sql database. That works perfectly.=20
There is a second way to authenticate. In germany there is a company call=
ed=20
dokcheck.de, they provide authentication services for medical staff. So y=
ou=20
only have to have one account at dokcheck and can enter nearly every=20
pharmaceutical site. So it's similar to adultcheck.com or other auth serv=
ices=20
like.
My primary idea was to use login manager features to try a login request=20
against several user sources (thats what login manager can do) and I thou=
ght=20
of a source like "generate a request at dokcheck.de, get an answer and le=
t=20
them in". But this company won't allow the contents of the login form go =
to=20
my server. In technical terms: the action of the form is a www.dokcheck.d=
e=20
URL . After successful auth they redirect the users browser back to my se=
rver=20
and append any "hidden" form contents to the URL (get method). So my thou=
ght=20
was to generate a session token and send this token along to the auth ser=
ver.=20
I'll get it back when they redirect the client back to me and I can=20
authenticate the client. This won't be very secure, but that's no problem=
=20
since german law says nothing about weak authentication for this concern =
:-)
Currently the customer has a known user/password combination which is pri=
nted=20
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=20
			token is sent.=20
		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=3Dparam(-name=3D>'ac_name');
$pass=3Dparam(-name=3D>'ac_password');
%pars=3DCGI::Vars();
$np=3Dundef;
foreach $i (keys(%pars)) {
  if($i ne 'ac_name' and $i ne 'ac_password') {
    $np.=3D"&$i=3D".param($i)
  }
}
if($pass eq "bla") {
  $mp=3D'?type=3DA'.$np;
  print=20
redirect(-uri=3D>"http://tiburon.i.contrada.de:8080/Beta/B_Fachkreise/Doc=
CheckHandler".$mp);
}

This will redirect to the given URL with all form fields appended if the=20
password is "bla". The "type=3DA" parameter is something they will send t=
o tell=20
me if the client is a doctor or a nurse or whatever medical staff. One co=
uld=20
provide different contents on that.

I don't really authenticate the user. I rely on the info that is handed t=
o=20
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 migh=
t
>
> be wrong. It wouldn't really matter if the raise happened later. As lon=
g
> 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 transactio=
n
> 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 dum=
b
> 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 w=
ith
> > the form on it and the same session related code. That works. So it i=
sn't
> > a general problem of my installation or the session management. It mu=
st
> > have something to do with the login manager stuff. I'll dig into logi=
n
> > manager and see how things work there. I think the guess about the ra=
ise
> > 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

- --=20
	Uwe C. Schr=F6der

- --
Uwe C. Schr=F6der                                      ConTrada Consultan=
ts
Lindenstrasse 15                                     Tel/Fax: +49 8294 80=
070
D-86477 Adelsried                                    Mobil:   +49 172 853=
2352
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE63AI+TJbO78VG0aIRArhRAJ9lk6aB7/pvtlVvJQY1wZLp6jmFvwCgplNj
WpqZdnryyGTSN1Ex9lTRSJg=3D
=3DsjBs
-----END PGP SIGNATURE-----