Add Attribution Header to wire spec

[ntrinquier]

Before this PR

After this PR

==COMMIT_MSG==

==COMMIT_MSG==

Possible downsides?

[uschi2000]

Alternatively, did you consider using the existing user-agent mechanism to convey attribution?

[ntrinquier]

I considered it and thought that they could have slightly different meanings, e.g.:

User-Agent: foo/1.12.0
X-Conjure-Attribution: Project foo <[email protected]>

or

User-Agent: python-requests/2.2.1
X-Conjure-Attribution: 84273d73-7527-45ac-ac02-c2e61cbdc5b3

I don't feel strongly attached to having a new header.

[iamdanfox]

Please could you flesh out the motivation for this? It seems strange to be including another string header that supposedly identifies the caller - this could easily be forged by other callers (if this is bad for the use case, then I think you should parse the userId out of the authorization bearer token). If forgery doesn't matter, then I think the existing user agent should be sufficient?

[ntrinquier]

@iamdanfox The high level goal is to identify the functional "entity" responsible for requests. By entity I do not mean a user or a micro-service, but the entire block of micro-services or front-end applications that make up a cohesive whole.

As for the use case: The goal is to be able to safely remove endpoints. In my experience in environments with thousands of users, front-end apps, or micro-services, tying requests to these things is not enough to safely remove endpoints because:

a. users are generally end users who know nothing about requests, so userId is not helpful (this is typically what happens for front-end applications);
b. when they are not end users, they are service users, and it requires human investigation to know who to contact (this is typically what happens for back-end applications).

---

On forgery:

You are right, this is something to consider. For the use case I described (being able to monitor usage of endpoints to safely remove them), the worst thing that could happen is someone making requests with someone's else's attribution ID, thereby feeding you with incorrect information with regards to who is using what endpoints. However in the context of endpoints removal, this is something I'd be OK with (i.e. if an application breaks because it did not provide its unique ID, too bad...).

It might not be sufficient, however, if this starts to be used for other use cases such as rate limiting or API billing where trusting the "functional identity" is obviously more important.

On user-agent:

It very much looks like this would be OK. My only concern with that would be losing information that can be valuable (e.g. the type of browser/OS).

[stale]

This PR has been automatically marked as stale because it has not been touched in the last 14 days. If you'd like to keep it open, please leave a comment or add the 'long-lived' label, otherwise it'll be closed in 7 days.