Django auth -> valid session on Grafana behind NGINX

Grafana
1

Hi you all guys,

I have nginx in front o Django with WSGI.
I authenticate a user with Django and I would like the same user, who exists on Grafana, is already logged in his own default dashboard.

I fell that valid options are 2:

  1. use the auth.proxy and set the X-WEBAUTH, but to prevent header spoofing NGINX should set it (or remove it) only if it found a valid (or an invalid) session cookie for Django
  2. create Grafana session table in PostgreSQL db, and let Django and Grafana session tables synchronize

Option 1: NGINX sets X-WEBAUTH

I have no clue on how to do it, maybe using some conditions on one of the vars in http://nginx.org/en/docs/varindex.html ?

Options 2: Synchronize Session tables

I have created my session table, I can fill it with the same hex key of the sessionid cookie used in Django, I can set the “expiry” field with unix epoch timestamp BUT I have no idea on what it goes in the “data” field.

I have searched in the Grafana source code in the Github repo, in the go-macaron framework (is Grafana based on it?), it seems to be a gob encoded struct, but I have no experience in go and I have not found a program to read the content and maybe create the same data with python/Django or a TRIGGER in the database.

I have seen that if I provide a valid key in the session cookie and in the table the data field is NULL, it is populated, but still the login form happens.

I have seen that there is a “remember” cookie that seems to affect the behaviour, and in the source code it is referred as SuperSecureCookie so damn … it does its work very well if so! :wink:

Example of row with valid session data

-[ RECORD 6 ]--------------------------------------------------------------------------------------
key    | 259cbf49202cdf5f
data   | \x0eff81040102ff82000110011000001cff82000106737472696e670c05000375696405696e74363404020002
expiry | 1505547260

Example of row with session data created by Grafana when session data is NULL

sessionid cookie “forged” (you can think “passed by Django”)

-[ RECORD 1 ]--------------------------------------------------------------------------------------
key    | 3212aabbcc
data   | \x0eff81040102ff820001100110000004ff820000
expiry | 1505548885

Last note and conclusions

Django is a framework that can be versatile on SessionStorage, so I can change it, but I do not think it will address the issue

Conclusions: I am stuck with this User Story. In my job career I have integrated a bunch of different web applications, but it seems that with Grafana I am taking the wrong path.

Thank you in advance
fero

1 Like
2

Nobody knows the trouble I see… nobody knows… :wink:

bump.

Anyone can share some ideas on integrating authentication? I cannot believe that… :smile:

3

I try a re-bump, for several days I have abandoned this task, now I would like to close it. Rebumping is done because I have changed category for this question (from Support->Configuration to Support).

Thank you guys, I am not going to disturb you often
Luca

4

Hi, I am facing similar problem. I would like to know how to share the authentication between Django and Grafana.

5

I come up with a workaround that is to create a new Grafana API key for each Django user, then once user logged in with Django, the system auto add the authorization header so that they can view the graph.

6

@chubao , thanks to Grafana’s guys I met at FOSDEM (@carl1 for sure, and another one I don’t remember sorry ;-)) I figured out the solution to implement an application reverse proxy who:

  • verifies the Django authentication
  • proxies the request to Grafana by injecting the authentication header configured in the [auth.proxy] section in grafana config

In this way you do not need an API-KEY for each Django user. I think it is a good way to go.

I have put all instructions and snippet in the GitHub Gist https://gist.github.com/feroda/c6b8f37e9389753453ebf7658f0590aa

Thanks Grafana’s team, and thanks to FOSDEM! :wink:
fero

P.S: Grafana 5 is very very beautiful!

1 Like
7

is whitelist the only security mechanism to prevent malicious login?

also whitelist does not seem to work properly when using docker containers (container IP will not be static)