steverice

Hello,

Thanks for your continued interest and use of the PagerDuty API.

We're writing to let you know that as of November 4th, 2015, we will be discontinuing the ability to authenticate against the API using HTTP Basic Authentication (PagerDuty username and password), which has been deprecated since mid-2014.

We are doing this to improve security of PagerDuty accounts by limiting the spread of PagerDuty user passwords, which are difficult to audit and revoke should they become compromised.

Additionally, the need to authenticate a user via HTTP Basic Authentication imposes a performance penalty on every API request due to the robust hashing techniques we use to store and validate user passwords. This is done by design to make brute forcing passwords computationally infeasbile.

steverice

module Api
  module V2
    class SchedulesController < Api::V1::SchedulesController
    end
  end
end

steverice

An example of a relationship is Notification Rules, whose primary meaning is as a link between a user and a contact method. No individual notification rule has a unique, name-worthy meaning, and so they are handled (read and written) only as a collection. There is no compelling reason to update a single notification rule in place rather than replace the entire object with a new one. While this might seem like a significant loss of functionality, data shows that a trivially small number of clients outside of the PagerDuty web app are using it:

• over the last 30 days, only 11 requests were made to PUT notification_rules/id using non-cookie authentication, and all by the subdomain redacted. While the mobile team experimented with it in the latest "Edit Notification Rules" update in 3.6, they've confi