[Top][All Lists]
[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