Reset user session in LDAP configured environment

1

Hi,

One of our users has mistakenly been granted a higher level of access than is appropriate. I have reset the user’s role within Grafana, which solves the problem in the long term, but in the short term they still have a preexisting open browser session with the privilege of the wrong role.

What can I do to force the role change to take effect? I don’t want to ask the user to sign-out of their browser session and back in because there is no positive feedback for me that the necessary action has been taken.

Is there a way I can terminate the user’s session within Grafana?

If not then I had some ideas about how I could force it, but I wanted to know which would be effective rather than resorting to trial and error:

  1. Delete their account - I tried this on a test account and it crashed the test account’s browser session, so not viable.
  2. Restart the Grafana service - ineffective
  3. Reboot the Grafana server - haven’t tried this and not sure if this would make a difference
  4. Reboot the user’s PC - drastic but would probably work?

Thanks in advance for any assistance.

r0tty

2

Hi,

Restarting the server will have the same effect as restarting the service. Rebooting the client PC won’t help if the browser remembers the session cookie.

By default, sessions are stored in <grafana directory>/data/sessions.
http://docs.grafana.org/installation/configuration/#session

Stop Grafana, delete this folder’s content, and start Grafana. Everybody will have to log in again, and the currently configured privileges will apply.

3

Hi Adeverteuil,

Thanks for that. I tried as you suggested, but I don’t think it has worked.

I had an open session in my browser and I performed the following commands on the server:

 # systemctl stop grafana
 # cd ${GRAFANA_HOME}/data
 # rm -rf sessions
 # mkdir sessions
 # chmod 700 sessions
 # chown grafana: sessions
 # systemctl start grafana
 #  systemctl status grafana

My Browser session survived this procedure - I was not asked to sign-in again.

It is not as big a problem as I thought though. I experimented with setting my own account’s permission to viewer and saw that although I could still see admin menus I was getting a permission denied error in some places, and was unable to grant myself admin privilege.

r0tty

4

Hello r0tty,

It’s good to know that your experimentation has demonstrated that user actions are restricted even if the GUI is not updated.

Maybe erasing the sessions directory didn’t work because an external session store is configured? Sessions are stored in /sessions by default but this can be changed for MySQL, PostgreSQL or Memcached, in which case deleting /sessions would have no effect.