Re: [Gnumed-devel] Re: web frontend/patient singleton

[Karsten Hilbert]

> yes ,  gnumed uses the postgres authorization system which is sensible,
Version 2.0 will (if I have my way :-) somewhat change to
revolve more around the concept of "care team". I image row level
access control using views that constrain tuple visibility at the
care team level.

> although this makes connection pooling more complicated. I haven't 
> thought how to
> integrate tomcat's connection pooling with the gnumed 
> authorization-by-connected-user, but there is a sql command
> "set session authorization 'username'" if the 
> original connecting user is a superuser, so that could be the workaround.
A GnuMed web frontend should never ever run as a super user.
It may run as a "connection pooling" user and use set session
authorization. If you find out anything about that I'd be
interested to hear it since doing so will likely defy our
auditing as we currently use CURRENT_USER. There is, however,
also a SESSION_USER which we might need to use instead.

> agreed, linux handles lots of processes easily and gmPG, gmDispatcher, 
> gmCurrentPatient , everything, is setup to handle just one patient at a time.
While no care has been taken to *allow* for multiple patients
I don't see where gmDispatcher is patient-aware, gmPG is so
only when the backend listener is used. And since the clinical
record object is connecting to the listener that makes it tied
to one patient at a time.

However, I don't see any problem at all having a process per
user/patient.

Karsten
-- 
GPG key ID E4071346 @ wwwkeys.pgp.net
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346