Skip to content
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

Send a custom header & value #25

Open
laconc opened this issue Aug 1, 2017 · 3 comments
Open

Send a custom header & value #25

laconc opened this issue Aug 1, 2017 · 3 comments

Comments

@laconc
Copy link
Contributor

laconc commented Aug 1, 2017

Suggestions from @bryonjacob:

  • for every account, generate an OUTBOUND_AUTH_TOKEN - this can be a type 4 UUID. Store it on the agent record
  • show it to the user on /settings/advanced, right next to their API token(s). Give them the ability to reset it, maybe.
  • on every outbound request "webhook" generated by a user, send that value in a custom header.
  • the receiving user can use that to know if the request is really coming from us (and will ignore that header if they don't know what it is)
@markmarkoh
Copy link
Contributor

What if a different user executes the sync of an existing file?

Given: UserA created a dataset
Given: UserA adds sync'able file by URL
Given: UserA adds UserB as contributor
Given: UserB forces a sync of existing file

Would the "webhook" sync be made with UserB's token or UserA's?

@bryonjacob
Copy link

great question! the answer should be UserA's

the sync record should tie back to the user account of the authenticated user that created the sync record - that user had access to their own credentials, and therefore has access to the paired outbound token, so it can be configured on the receiving end.

and, since in this case UserA and UserB both likely work for the same org, they could either have a OrgIntegrations account that is owned by the organization and has a shared api token (and outbound) that they would all share OR their server could keep a list of outbound tokens that they will accept (e.g. UserA's and UserB's) if they want their webserver to respond to sync requests authorized by UserA and UserB

@rflprr
Copy link
Contributor

rflprr commented Apr 9, 2018

@bryonjacob We'll deliver an HMAC SHA256 hash of the webhook payload, signed with the OAuth client's secret if the webhook was created via our the public API. If users set up webhooks by hand, they'll be able to specify any headers they want.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants