[Zope] Re: CoreSessionTracking

[Chris McDonough]

"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&_ZopeId=828367182?other=value

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