Requires cookies for affected user monitoring, even when RUM isn't wanted
Closed this issue · 3 comments
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 a RaygunIdentifier 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?
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
Without the cookies we can't give you a number of unique users impacted
Key thing for me is that the providers for other languages aren't injecting cookies by default. (e.g.
https://github.com/MindscapeHQ/raygun4ruby#affected-user-tracking) - they just allow you to specify the token, and maybe show you how you might persist it (in your own code) in the examples - (if I'm interpreting the examples correctly.)
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.
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
support how our customers are architecting their apps
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 setcookie, or $_SESSION), but you don't know whether it's correct to use them because most frameworks don't directly use $_SESSION or setcookie, preferring to work with their own request and session objects (and fair enough too; the standard stuff is procedural and awkward!)
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 ruby == rails without a railtie is a rough equivalent of assuming the response is available if php_sapi_name() != 'cli', and either is a PITA if you guess wrong.)
Proposal
All 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 RaygunIdentifier that'll be used, from outside the client class. It's completely backward compatible, as far as I can tell.