Open AnnoyingTechnology opened 10 months ago
Hey @AnnoyingTechnology,
thanks for reporting this. Just to clarify: you are talking about the first of the two cookies (the one starting with ph_phc_
) which is problematic, while the authentication
cookie is fine?
Edit: You are explaining that already in the first sentence, sorry.
Hi @AnnoyingTechnology,
if you disable telemetry globally (graylog.conf ) the cookies gets not created.
# New for 5.1 disable telemetry global for all users
telemetry_enabled = false
best regards
Wow, that's unexpected but it checks out.
Thanks!
(still a security concern for people who don't notice and leave this enabled)
Related: #15527
Thanks, @coffee-squirrel! I think disabling telemetry for now is a valid workaround if the overly wide cookie domain is an issue for you.
I think we should try to fix that nonetheless, as we want users to have as little privacy/security issues as possible when deciding to send telemetry data, because it helps us improving the product (finding out if features are actually used, at which scale, which user flows can be streamlined, etc.).
The cookie is set by the Posthog client library and it looks like they are doing this (setting it to *.domain.tld
) on purpose to allow cross-domain tracking. We do not want this and it makes little sense for an on-premise product, so I hope there is a way to disable it.
Hi @AnnoyingTechnology,
if you disable telemetry globally (graylog.conf ) the cookies gets not created.
# New for 5.1 disable telemetry global for all users telemetry_enabled = false
best regards
Probably an other issues, but users not having telemetry disable could not connect to graylog after upgrading from 5.1 -> 5.2. Graylog is behind nginx with oauth2-proxy doing the authentication.
After setting telemetry_enabled = false
they could login again. By checking the Cookie, it was very long containing special chars, so probably the processing in graylog changed for 5.2?
Hey @hydrapolic,
do I understand you correctly that with Graylog 5.2 you were not able to login when telemetry was enabled? What error did you see? Can you create a separate issue for this?
Hey @hydrapolic,
do I understand you correctly that with Graylog 5.2 you were not able to login when telemetry was enabled? What error did you see? Can you create a separate issue for this?
Yes, after upgrading from Graylog 5.1 to 5.2, users were unable to login, they received error 400. My user was able to login because I had telemetry disabled previously. After setting telemetry_enabled = false
globally, users were able to login.
The only difference I saw was the cookie, mine was shorter, while the users had telemetry data in the cookie. Probably the cookie processing changed in 5.2 so that it's more stricter what to accept?
Unfortunately I don't have the logs any more, but I see no errors in the graylog log from that day, just http 400 from graylog in the nginx log.
We use oauth2-proxy with Azure for password management.
We experienced the same issue as @hydrapolic, created a separate issue since the cookie broke it for us, but the domain is irrelevant here.
Regarding the actual issue here: The top-level domain cookie does not make any sense at all, since we use graylog.<environment>.example.com
with multiple instances and these cookies would get mixed up constantly.
Just had an other web application refuse to work because the Graylog cookie under the top-level domain was to big for it to handle. Setting http_external_uri
didn't help.
Graylog creates two cookie. One is correctly created in .subdomain.domain.tld the other is created in .domain.tld
Expected Behavior
Graylog should not escape its subdomain.
Possible Solution
Create all cookies in the subdomain configured in server.conf
Steps to Reproduce (for bugs)
Context
This sends a cookie to all ours applications, websites, etc. It is :
Your Environment
nginx as a reverse proxy
There doesn't seem to be a workaround, as the cookie is deposited using Javascript, so nginx cannot rewrite it on the fly.