chore(deps): bump umami-ruby from 0.1.3 to 0.3.0

[dependabot]

Bumps umami-ruby from 0.1.3 to 0.3.0.

Release notes

Sourced from umami-ruby's releases.

v0.3.0 — Username/password authentication actually works

TL;DR

If you authenticate against a self-hosted Umami instance with username/password, versions <= 0.2.0 were broken: the login itself succeeded, and then every subsequent API call failed with HTTP 401. This release fixes that, hardens the login path, and makes 401/403 responses raise Umami::AuthenticationError so long-lived clients get an explicit re-authentication signal. Access-token authentication was never affected.

gem "umami-ruby", "~> 0.3"

---

The bug: a memoized connection built one instruction too early

Anatomy

Umami::Client memoizes its Faraday connection, and the Authorization header is written into the connection at build time:

def connection
  @connection ||= Faraday.new(url: uri_base) do |faraday|
    # ...
    faraday.headers["Authorization"] = "Bearer #{@access_token}" if @access_token
    # ...
  end
end

Faraday::Connection freezes its header set when constructed — it does not re-read @access_token on later requests (Faraday docs — customizing the request).

The username/password flow, however, needs a connection before it has a token, because the login endpoint is itself an HTTP call:

def authenticate
  response = connection.post("/api/auth/login") do |req|   # ← memoizes @connection with NO auth header
    req.body = { username: @username, password: @password }.to_json
  end
  @access_token = JSON.parse(response.body)["token"]        # ← token stored… into an ivar nobody re-reads
end

Sequence of events for Umami::Client.new with credentials:

1. initialize → authenticate (because @access_token.nil?).
2. authenticate calls connection → @connection is built and memoized without an Authorization header (@access_token is still nil at this instant).
3. POST /api/auth/login succeeds (Umami API — authentication), @access_token is set.
4. Every subsequent call (client.websites, client.website_stats, …) reuses the memoized, header-less connection → the server answers 401 Unauthorized → the gem raised Umami::ClientError.

The failure mode was maximally confusing: the login demonstrably succeeded (wrong passwords did raise Umami::AuthenticationError), yet the very next call reported Client error: the server responded with status 401 for GET /api/websites.

Why the test suite never caught it

... (truncated)

Changelog

Sourced from umami-ruby's changelog.

[0.3.0] - 2026-07-24

Fixed

• Username/password authentication against self-hosted instances actually works now. Since the connection memoization was introduced, authenticate built (and memoized) the Faraday connection in order to POST /api/auth/login — before @access_token existed. Faraday bakes headers in at connection build time, so every request after a successful login went out without an Authorization header and failed with 401. The token-based flow was unaffected, which is how this survived: docs and tests exercised logins, never "login then call an endpoint". authenticate now drops the memoized connection after storing the token so the next request rebuilds it with the Bearer header, and the new test/integration/authentication_flow_test.rb pins the full lifecycle (login → authorized request → connection reuse without re-login).
• authenticate raises Umami::AuthenticationError when the login response is a 200 without a token field, instead of leaving a client that 401s on every call with no hint why.

Changed

• HTTP 401 and 403 responses now raise Umami::AuthenticationError instead of the undifferentiated Umami::ClientError, giving long-lived clients a re-authentication signal (expired/revoked token, insufficient permissions). To keep existing rescue Umami::APIError handlers working — they used to catch these as ClientError — AuthenticationError is now a subclass of Umami::APIError (previously it subclassed Umami::Error directly). Code matching Umami::ClientError specifically for 401/403 must switch to Umami::AuthenticationError.

[0.2.0] - 2026-02-02

Added

New Endpoint Categories:

• Me endpoints: me, my_teams, my_websites - Get current user info and resources
• Admin endpoints: admin_users, admin_websites, admin_teams - Admin-only endpoints for self-hosted
• Sessions endpoints (8 new methods):
  • website_sessions - Get sessions within a time range
  • website_sessions_stats - Get summarized session statistics
  • website_sessions_weekly - Get session counts by hour of weekday
  • website_session - Get individual session details
  • website_session_activity - Get session activity
  • website_session_properties - Get session properties
  • website_session_data_properties - Get session data property counts
  • website_session_data_values - Get session data value counts
• Realtime endpoint: realtime - Get live stats for last 30 minutes
• Links endpoints: links, link, update_link, delete_link
• Pixels endpoints: pixels, pixel, update_pixel, delete_pixel
• Reports endpoints (13 new methods):
  • CRUD: reports, create_report, report, update_report, delete_report
  • Specialized: report_attribution, report_breakdown, report_funnel, report_goals, report_journey, report_retention, report_revenue, report_utm
• Website stats endpoints:
  • website_events_series - Get events series with time bucketing
  • website_metrics_expanded - Get detailed metrics with engagement data
• Events endpoints:
  • website_events_list - Get paginated event details
  • website_event_data - Get data for individual event
  • website_event_data_events - Get event data names and counts
  • website_event_data_fields - Get event data fields
  • website_event_data_properties - Get event properties
  • website_event_data_values - Get event data values
  • website_event_data_stats - Get aggregated event stats

Configuration:

• request_timeout= setter - users can now customize timeout via Umami.configure block
• New UMAMI_CLOUD_SEND_URL constant for the Cloud send endpoint URL
• Optional user_agent: parameter to send_event method for custom User-Agent strings

... (truncated)

Commits

• See full diff in compare view