Situation
Attempting to add a list item on an active (in an encounter) drop-down list from the form causes an authentication error. This is on a macOS Chrome session over HTTPS.
OpenEMR Version
I’m using OpenEMR version 5.0.1(7)
I’ll bet this is a csrf prevention error (this was added in some parts of 5.0.1(7)), but there should definitely also be a message going to the php error log. Are we sure that the php error log is not somewhere else?
Also, what is the exact string that you see on the screen?
-brady
I saw this issue again today when I added a new “county” to the list of counties (using a list add on the demographics page). Prior to this error, I did log out of one of the open OpenEMR tabs … I did not realize that the tab I was working on (a particular patient’s chart was linked to that session because there was another open tab that had identical content). I think the authentication error was most likely due to the fact that the “parent window/tab” was logged out of without warning that there was a “child” session/tab. I lost very little information because all I was doing was putting the “county” for a particular patient. I’m not suggesting that we implement “reference counting” the “child” sessions … just that “child” tabs/sessions are opened, and it can get tricky to keep track of what child session goes with what parent.
The parent window/tabs are reset when a new user is opened in another openemr instance/tab:
This bug is likely because a link was clicked on in the other session that did not run top.restoreSession() or that the code that allows the Add new county does not run top.restoreSession() .
What we really need to do (hopefully for version 5.0.3) is standardize OpenEMR’s use of login/session to be like any other web software, and not try to support separate logins per user in the browser. See here for details:
This would be a huge improvement in both robustness (ie. no more of these weird session issues) and security (allows use of cookie_httponly, which provides great cross scripting prevention since js then has no access to the php session id).
A standard website like an "Army Ready-to-Eat Meal (Meal, Ready-to-Eat - Wikipedia): the standard individual field ration get its job (like nutrition, etc.) done reliably but leaves a lot to be desired (supposedly it tastes like any sort of food out of a can).
I would like to advocate we move a bit further up the website performance (or cuisine) ladder. It is very common for me (and other Internists) to be working on one patient and to need to jump to a different patient to answer a critical question or make an important order. Sometimes we may be seeing 2 or 3 patients at the same time (one patient is filling out paperwork, another patient is getting a breathing treatment, and another patient is being examined by me). It is critical for me (and my scribe or nurse) to be able to jump back and forth between different patients quickly … much more quickly than it takes to load a patient chart. Thus, we could have multiple browsers open but that’s a bit symptomatic of an UI not suited to the task (used to see this often with other EMRs … this is becoming less common).
Take a look at this article:
More specifically … Perhaps we could reorganize the UI as follows, with the patient finder and individual patient “chart” tabs at the top level and tabs related to a particular patient chart subordinate, further down:
What do you think? Is this feasible? As a practical matter (browser and machine performance limitations and load on the database) there might be an upper limit on how many charts a user can keep open at a time otherwise other issues like dropped connections might come into play.
–Ralf