Logging already works. It is just not documented anywhere.
API#initialize accepts http:, and API#http chains onto whatever it is given
(@http.headers(...).use(:auto_inflate)), so any http.rb feature composes:
require "logger"
AmazonAds::Campaigns.new(
region: "NA",
access_token:,
profile_id: "123456789",
http: HTTP.use(logging: { logger: Logger.new($stdout) }),
)Confirmed against http 6.0.4, which ships HTTP::Features::Logging. The
instrumentation feature is available the same way for ActiveSupport::Notifications.
Proposal
Document this in the README rather than adding a logger: keyword. A dedicated
kwarg would duplicate an existing seam and give us two ways to do the same thing.
The docs should carry an explicit warning: HTTP::Features::Logging writes all
request headers at debug level, which includes Authorization: Bearer <token>.
Anyone enabling debug logging against production is putting live access tokens in
their logs.
Worth deciding whether that warning is enough or whether we should ship a small
redacting wrapper alongside it.
Logging already works. It is just not documented anywhere.
API#initializeacceptshttp:, andAPI#httpchains onto whatever it is given(
@http.headers(...).use(:auto_inflate)), so any http.rb feature composes:Confirmed against http 6.0.4, which ships
HTTP::Features::Logging. Theinstrumentationfeature is available the same way for ActiveSupport::Notifications.Proposal
Document this in the README rather than adding a
logger:keyword. A dedicatedkwarg would duplicate an existing seam and give us two ways to do the same thing.
The docs should carry an explicit warning:
HTTP::Features::Loggingwrites allrequest headers at debug level, which includes
Authorization: Bearer <token>.Anyone enabling debug logging against production is putting live access tokens in
their logs.
Worth deciding whether that warning is enough or whether we should ship a small
redacting wrapper alongside it.