gnumed-devel
[Top][All Lists]
Advanced

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

Re: [Gnumed-devel] choice of web frameworks


From: Jim Busser
Subject: Re: [Gnumed-devel] choice of web frameworks
Date: Thu, 15 Jul 2010 15:45:21 -0700

On 2010-07-12, at 8:13 AM, Sebastian Hilbert wrote (below Luke):

>> given that the HTTP protocol is stateless, most web server frameworks
>> revolve around the idea that threads are totally interchangeable, that
>> all application state revolves around the _database_ (once you have
>> got that session id out of the cookie).
>> 
>> so, one thread could be doing one user one moment, and then next query
>> the exact same thread is used for a totally different user, because
>> the session id it was handed by the framework was totally different.
>> 
>> do you see what the problem is?
>> 
> No. But hopefully after I reread that a couple of times I will see the 
> problem.

I have more basic questions, if that's ok:

- each thread provides something like a channel through which data passes?

- http threads are a liability because the stream of data could be read along 
the internet and so for medical practice the threads should be https?

- can a thread be used by more than one user at a time because --- if it can 
only be used by one user at a time --- what makes it a vulnerability... that 
someone can gain occupancy inside this thread and the database risks assuming 
the user is the same as previous?

- if each cookie is browser specific, a user who accessed GNUmed via more than 
one browser would have a different cookie (and connection) for each? is this 
any means to achieve more than one instance of gnumed from the same machine 
(for example, slave mode) since I assume is may not be possible or impractical 
within a single browser e.g. multi-tabbed?

- what happens when different individuals would gain access to use the same 
machine and, by firing up this machine's browser (say, to a non-passworded or 
generic user account) and therefore re-accessing the cookie to the database... 
would this person be assumed to be continuing that never-die connection *as the 
previous user*

- how is what Luke's method could offer different/better than what current 
browser-based EMRs (openEMR, Oscar) offer in terms of security (where, in this 
case of security, we mean the intended users gaining access to the intended 
data, but only to the intended data) ??

-- Jim




reply via email to

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