Last Friday, I made a configuration update enabling disable_sanitize_html. I restarted the server after the change and didn’t have a problem all weekend. I tried logging in this morning, but I can’t be authenticated. Here’s a clip of what’s happening on the UI:
As you can see, the message indicates that I have been authenticated and have successfully logged in. However, I’m redirected back to the login page. I checked the server after changing the mode to development and trying again. Here are the logs since the server restart:
The only thing that stands out to me besides one of the plugins appearing to be a duplicate is that it is saying “user token not found” and “failed to look up user based on cookie”. So, I tried logging in with the browser in private mode and tried using a different browser. I’m getting the same issue. I’m not sure what has changed from my configuration edit until now, but I’m a little stumped as to what I need to do.
Please verify if cookie being set when logging in using chrome developer tools or similar. I think you may have an issue with the cookie SameSite attribute
I’ve checked out the release notes and the upgrade notes. I’m not sure how much of that applies. I’m not running it with SSL. So, I don’t think I should be setting my cookie_secure to true.
I think you’re on to something. No cookies are being set at all. Nothing is being saved to session storage either. My config has the default setting though: ;cookie_samesite = lax
I changed the root_url to reflect my domain, and that fixed it. I left it as it was commented out when I set it up because I assumed the domain would just bring rendered if I changed only the domain since the default.ini is configured like this:
I’m having the same problem with LDAP auth. When I log in, it flashes the green popup saying I’m in, but then goes to the home page and I’m still not actually logged in. Log file has:
… lots of ldap stuff… lvl=dbug msg=“user auth token created” logger=auth tokenId=20 userId=3 clientIP=1.2.3.4 userAgent=“Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.121 Safari/537.36” authToken=0a4d29ddaf15e40dd12141410cfe0ea9f4ad763
t=2019-03-13T12:00:45+0000 lvl=eror msg=“failed to look up user based on cookie” logger=context error=“user token not found”
My installation is using grafana 6.0.1-1. We have been running 5.4.3 and the config file started from there. We use nginx as a proxy to redirect from port 443 to 3000. cookie_secure was false (I tried both true and false). Tried cookie_samesite = lax and none. We had not changed the root_url but I tried setting it to community.grafana.com - no luck…
Results seem to be the same regardless of what settings I’ve used. I’m unfortunately not an LDAP expert - but LDAP doesn’t seem to be the problem (we can log in fine with the previous release, and it finds the user info in this release). So what do I need to do to get logged in with the new version? Thanks very much…
@nbcohen seems like the cookie are not persisted correctly in browser. Could you use chrome developer tools, network tab + preserve log. Then go to login page. Clear all request in the network tab. Then log in and check the request corresponding to your login post request. Mine looks like this:
We are front-ending grafana with nginx. The nginx config redirects from port 443 to community.grafana.com
In the grafana.ini file, I have not modified the root_url. It is set to be:
;root_url = %(protocol)s://%(domain)s:%(http_port)s/
We are upgrading from version 5.4.3. I left the 5.4.3 config file more or less untouched from what we were using. I added an [auth] section that looks like:
In general you shouldn’t change Grafana’s default config since it makes upgrades hard. Instead add an custom config file where you override your changes, see configuration documentation.
The leading ; means that the line is commented out, refer to configuration documentation. But since you’re public facing url is you should configure root_url in the following way, refer to configuration documentation:
That was the first thing I tried last week - I added the secure cookies and changed the root url. Didn’t work. I had to delete and re-install 5.4.3 last Friday for someone’s testing, but I rebuilt the tenant today with 6.0.2. I will go through that documentation again and try with the revised URL and secure cookie entries again tomorrow morning. I’ll let you know what happens. Thanks.
It has been a while since I tried working with v6.x. Am trying to get back to it. I installed v6.2.5. If have secure cookies set, the root url points at the host, nginx is relaying to port 3000 and I get this from the chrome developer tools:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/75.0.3770.80 Safari/537.36
I enabled LDAP debug logging and it finds my username and authenticates me. But there is no reference to setting a cookie like you showed in the image above. I get the green flash indicating that I’m authenticated and then I remain on the login page. Where should I be looking for info on what is happening (or not happening) with cookies? I have cookie_secure set to true, and cookie_samesite set to none (tried it with lax as well).
We are not certain, but it appears that our problem may be related to the fact that we are using a Percona database. We stood up a standalone system using ‘mariadb’ and it worked. We repointed our cluster to the mariadb instance and that worked as well. For some reason, when we tried running inserts into the user_auth_token table (even from the command line) they would hang or time out, and we got indications that tables were locked, when they obviously were not.
For now, I am not going to continue down this road. We are (from a corporate perspective) starting to migrate our some of our mysql/maria/percona databases to postgres where that is possible. I am going to attempt to migrate my grafana environment to postgres and see if our login problems go away…
I was also facing same issue with mysql galera cluster. Moved to single node mysql server , it worked fine.
While doing more debugging , i found that grafana was trying to read auth token without committing the write transection. I Enabled global auto-commit in galera cluster, which fixed this issue for me.
