[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] GNUmed web interface - authentication

From: Karsten Hilbert
Subject: Re: [Gnumed-devel] GNUmed web interface - authentication
Date: Wed, 13 Oct 2010 17:57:44 +0200
User-agent: Mutt/1.5.20 (2009-06-14)

On Tue, Oct 12, 2010 at 03:51:08PM +0100, Richard Taylor wrote:

> Your explanation is very clear. I can see what you are attempting to do.
> It is not as unusual as you might think. I agree that most web
> applications will hold a single database connection, authenticated as
> the 'webapp'. Some that I have been involved with hold a number of
> different connections as different 'roles' so that isolated parts of the
> application only get given a connection with specific permissions. This
> limits the damage that can be done by something like a SQL injection
> attack but it does not provide the audit trail back to the user.

Yes, and we do require a useful audit trail.

> I guess that you want to maintain a single place where
> user/role/permission management is performed and rely on the database to
> enforce what a specific user can, and can't, do to the data. Eminently
> sensible.

Single-point-of-failure vs. layers-of-security.

> For this approach to work the session information has to be persistent
> between requests. There are many ways of achieving this depending upon
> how elaborate the solution needs to be. It gets complicated when there
> are multiple front-end web servers in a hot-failover arrangement,

Very unlikely given the intended scope of GNUmed.

> One small point of note. The connection-per-user pattern of database
> usage does have scalability limitations. Postgres might start having
> problems if you have many hundreds of users connected at the same time.

a) not really given you've got the hardware and bandwidth
b) GNUmed isn't designed to scale to that (or intended to
   be used like that) anyways

GPG key ID E4071346 @
E167 67FD A291 2BEA 73BD  4537 78B9 A9F9 E407 1346

reply via email to

[Prev in Thread] Current Thread [Next in Thread]