Attempting to add a list item on an active (in encounter) drop-down list from the form causes authentication error

(Ralf Lukner MD PhD) #1

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’m using: macOS Chrome 75.0.3770.100 (Official Build) (64-bit)

Operating System
I’m using: macOS Mojave 10.14.1

Did you check the logs? Yes.
Was there anything pertinent in them? No. The logs are empty.

(Brady Miller) #2

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?

(Ralf Lukner MD PhD) #3

No error message there. Logging appears to be broken on my OpenEMR installation. I did an exhaustive search for error.log files and there is only one.

/var/www/localhost/htdocs/openemr # ls -l /var/log/apache2/
total 4
-rw-r--r--    1 root     wheel            0 Jul  7 02:00 access.log
-rw-r--r--    1 root     wheel            0 Jul  7 02:00 error.log
drwxr-sr-x    2 root     wheel         4096 Jul  7 15:32 old_logs
-rw-r--r--    1 root     wheel            0 Mar 19 22:47 php_errors.log
-rw-r--r--    1 root     wheel            0 Jun  3  2018 ssl_access.log
-rw-r--r--    1 root     wheel            0 Jul  7 02:00 ssl_error.log
-rw-r--r--    1 root     wheel            0 Jun  3  2018 ssl_request.log
/var/www/localhost/htdocs/openemr # find / -name error.log

The string that appeared was “Authentication Error” - I haven’t run into it since, but I am not trying to.

(Brady Miller) #4

Hi @Ralf_Lukner
To find your error log, recommend making a quick dummy php script with phpinfo() command in it. That should show the actual log file that is being used.

(Ralf Lukner MD PhD) #5

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.

Here is the error.log:
[Mon Sep 02 00:56:38.645788 2019] [php7:notice] [pid 9858] [client] OpenEMR CSRF token authentication error, referer:
[Mon Sep 02 01:02:14.708043 2019] [php7:notice] [pid 9895] [client] OpenEMR CSRF token authentication error, referer:
[Mon Sep 02 01:03:35.114906 2019] [php7:notice] [pid 9895] [client] OpenEMR CSRF token authentication error, referer:
[Mon Sep 02 01:04:54.739894 2019] [php7:notice] [pid 9899] [client] OpenEMR CSRF token authentication error, referer:


(Brady Miller) #6

Hi @Ralf_Lukner ,

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).


(Ralf Lukner MD PhD) #7


A standard website like an "Army Ready-to-Eat Meal (,_Ready-to-Eat): 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.