-
Notifications
You must be signed in to change notification settings - Fork 38
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Requires cookies for affected user monitoring, even when RUM isn't wanted #75
Comments
Without the cookies we can't give you a number of unique users impacted (e.g. 10k errors - might be 10 users, might be 10k users, that's valuable in prioritising fixes). Having said that, we've been thinking recently about an intuitive way of supplying a token from a session store without needing cookies (e.g. you could put a session ID value in the block and we wouldn't bother using cookies). This isn't something we'd just suddenly add because we want to consider the various different ways that folks might want to manage user id. Also, we'd want more than a session id, it needs to be a user token - across sessions, even for the crash reporting side of things. Setting a UUID in a cookie solves that for the most part. Open to discussions around how to do this, we obviously want to minimise any performance implications, as well as support how our customers are architecting their apps. Hope that helps answer the thinking @dominics |
I have a branch we can punt around now @CmdrKeen :D
Key thing for me is that the providers for other languages aren't injecting cookies by default. (e.g.
Fair enough. But PHP shouldn't be any different from the other languages in this regard: the second-most common way to "manage" the ID (other than 'I don't care, just use defaults/cookies') is going to be outside of this library, and you're just going to want to set it without side-effects. Background
Yeah, it's problematic for me because I have a Resque worker pool managed by FPM. (That is: php_sapi_name() is not 'cli', as is tested in this library, but the HTTP connection available at stdout is not suitable to throw cookies at - it's not even a browser on the other end.) And it'd be problematic for anyone serving a similar internal PHP API or microservice (where the user in the context isn't just across stdout from the PHP process). PHP is a bit unique in how much you can't use the HTTP stdlib stuff from libraries that are intended to be universal: you have guaranteed access to a bunch of HTTP helpers (like So, you end up in the situation where you can't know how to manage persistent state across requests correctly, because libraries don't know if the parent project is Zend, or Laravel, or Symfony, or something else. Compare this situation to Ruby, and it should be exactly the same: raygun4ruby allows the developer to specify how the user information is obtained, and how it is persisted across requests. It doesn't assume you're using net/http and rails, and it certainly doesn't just grab your request object and mutate it (it uses railties and rack middleware instead) (i.e. I'm arguing that assuming ProposalAll that said, I realize this library should, as much as possible, be completely self-configuring. So, all I'm really asking for is an 'escape hatch' from the default configuration, that allows me to set the identifier if I know what I'm doing. So, I've created #81 - a small change that allows advanced users direct control of the |
Why can't I use affected user monitoring without a bunch of cookie headers being emitted? Is it because the user identifier is also passed to Pulse? If so, there should be a way to set
$this->user
on the client to aRaygunIdentifier
without emitting the cookies, for people who only want Crash Reporting + Affected users (and not Pulse RUM).If I have my own state storage (like sessions, like 99% of web apps), why do I need to carry additional state through every HTTP request, just to support a user identifier being supplied to error ingestion?
The text was updated successfully, but these errors were encountered: