- **status**: review --> in-progress - **Reviewer**: Dave Brondsema - **Comment**:
An API response of `"status": "ok"` and nested `"webhook"` dict seems weird, particularly when doing a GET. How about un-nesting the webhook details? The 200 or 201 status code is sufficient to represent the status I think. Oauth parameters can be passed as a URL param so for DELETE You can do ?access_token=foo and don't have to use an `Authorization:` header. That said, adding support for header-based oauth bearer tokens is nice. A few things on that: * There actually is a spec for it. So the `Authorization:` header value should start with just "Bearer " per https://tools.ietf.org/html/rfc6750#section-2.1 I.e. the `bearer_token_prefix` variable. * You have some `log.error` lines left in `RestController._authenticate_request` and `OAuthNegotiator._authenticate` * This should be a separate ticket or at least update the title of this ticket so we remember to point it out when we make a changelog in the next release. --- ** [tickets:#7832] APIs to manage webhooks** **Status:** in-progress **Milestone:** unreleased **Labels:** sf-4 api 42cc sf-current **Created:** Mon Feb 09, 2015 04:26 PM UTC by Dave Brondsema **Last Updated:** Mon Feb 23, 2015 01:31 PM UTC **Owner:** Igor Bondarenko We should support APIs to manage webhooks so that 3rd-party sites can use oauth to configure a webhook on behalf of a user. This is a common practice to make it easier for the user. --- Sent from forge-allura.apache.org because [email protected] is subscribed to https://forge-allura.apache.org/p/allura/tickets/ To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.
