Once bug 1160111 is fixed we need to deprecate the use of the legacy oauth-based authentication scheme and start using the new hawk scheme.

Comment on attachment 8670774 [details] PR 1042 Looks good :-) I guess we'll also later need a bug for changing the nodejs client.

Yeah I'll file a bug once we land this.

Commits pushed to master at https://github.com/mozilla/treeherder https://github.com/mozilla/treeherder/commit/a6b9d736ca6f360e489ff14ce60fe9d32a760d29 Bug 1209555 - add requests-hawk to requirements https://github.com/mozilla/treeherder/commit/527b60fabac0adfc2f29e978f7f6b50d7129b840 Bug 1209555 - bump up client version https://github.com/mozilla/treeherder/commit/be64542d11889e180a01266bc655656ff7346b8a Bug 1209555 - switch etl requests to hawk I added a create_credentials command to help setting up the initial development environment. The puppet setup now creates a new user and set it as the owner of the treeherder-etl credentials. https://github.com/mozilla/treeherder/commit/82d518682ea17fc3c52c1c064cd8eb674b5b2430 Bug 1209555 - Fix job_log_url permission classes

This PR added requests-hawk to the treeherder client setup.py, but it's not actually used inside the client directly at the moment. Instead users need to pass in an instance of HawkAuth themselves when instantiating the client. Whilst the HawkAuth boilerplate is minimal, I wonder if we should client a new class in thclient/auth.py called TreeherderHawkAuth that wraps HawkAuth, avoiding the need to specify `'algorithm': 'sha256'` each time, as well as using named parameters for neater use than needing to construct a dict to pass in as the `credentials` argument to HawkAuth? What do you think?

I thought about that but I don't have a strong preference. If we create a wrapper it will only be to make the requests-hawk api more intuitive, right? Maybe it's worth to propose a fix upstream instead? I'm happy either way.

Filed https://github.com/mozilla-services/requests-hawk/issues/8 / bug 1213857 :-)