Client information headers #31
Conversation
|
+1000 |
|
@ntotten had this on the roadmap I think, but the sooner we do it the better |
|
Nice Ben!! It was on our backlog as well but it's nice to see it implemented in the first SDK! On Thu, May 7, 2015 at 3:50 PM -0700, "Matias Woloski" notifications@github.com wrote: @ntotten had this on the roadmap I think, but the sooner we do it the better — |
|
Yes, @ntotten, @benschwarz and I are on the same room here :-) |
|
🎱 |
|
👍 good idea |
|
@benschwarz great, Lucky I only have to add the |
| let(:headers) { client.class.headers } | ||
|
|
||
| it "has the correct headers present" do | ||
| headers.keys.sort.should eql ['Authorization', 'Content-Type', 'User-Agent', 'X-Auth0-Client'] |
There was a problem hiding this comment.
I'd rather use expect syntax instead of should.
|
I just read the spec on the use of |
|
That's true @ntotten, also we can add all the information in the |
|
The one thing about user agent is that it doesnt work in the case of lock where we would add the version to the /authorize query string. |
|
@ntotten 👍 you're right |
Updated should syntax to expect
|
I've updated the proposal to not use @hzalaz I updated to use the newer Finally, the build on this project seems to be a bit flakey — fails then pretty much always passes on second run. |
|
@benschwarz yes, I've thought the brittle build was that fixed but I must have missed something. Will merge it now and fix the build later. |
I'd like to discuss the idea of adding some client information to our API libraries — these changes would need to be implemented in a all of our official clients, as well as requiring some effort on the devops, and data tracking sides. I'll do my best to explain why this could be such a valuable enhancement.
What I want to do
Add two headers to all of our API clients when they're talking to auth0 APIs. These headers would carry the "platform" of the client, and the "version", so in the case of this Ruby client, it'd have the following two headers:
To break it down a little bit: The client is "ruby" (language/sdk), and the version of ruby that we're using is
2.2.1. The client version corresponds to the semantic version used for this gem (at next bump, it'll be3.4.1)In addition, the each client library should allow "overloading" the client, for example, this ruby library might be used in rails applications. For the
omniauthlibrary, we could setAuth0::ClientVersiontoRuby/2.2.1 (Rails 4.2.2).Client side example:
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/42.0.2311.135 Safari/537.36?auth0_client=auth0.js/1.1.1What it'll give us the ability to do
Support & CSE
I understand I'm speaking for team @eugeniop a little here, but I can foresee that adding client information to an given companies requests (then store them in something like intercom) would make for really useful information when trying to help diagnose client issues, or help us point to relevant documentation.
Developer advocacy
Understanding the volume and capacity of clients that are in use (and also tracking package downloads from rubygems, npm, bower etc) helps the advocacy team understand the effect/results of efforts with vertical conferences and events (Eg, if we speak at a ruby event, do we get a client bump? Do we get sign ups?). Additionally, we can work harder to improve documentation or SDKs for the more popular platforms (or, perhaps the UNpopular ones). In short, data helps us better understand our work.
Statistics
(Mocked graph) — We could show API requests by client type, and then also intersect that information by region, or customer details.
Further to this, we could identify customers that are using older versions of clients that require updates, or help them deal with deprecations.
Webtask to store this in Google analytics anyone? (cc @tjanczuk )
Effort required to make it a reality
The changes to the Ruby client were conducted in less than an hour, and while this isn't an exact guide for all clients, its a good indication that we should be able to knock through the PRs pretty easily.
Feedback
Clearly, I'm not yet familiar with pitching features at auth0, nor am I aware of the entire way that this stack works. If you've got thoughts, pointers or general hand holding advice, please leave it below in the comments. From here, I can do my best to drive this through to the end.