mirror of
https://gh.wpcy.net/https://github.com/discourse/discourse.git
synced 2026-05-04 03:30:38 +08:00
Previously, when polling an RSS feed from a login-required Discourse site, the `api_key` and `api_username` query parameters were passed through in the URL. While #37840 fixed the HEAD→GET issue, API key authentication via query parameters still fails because `api_parameter_allowed?` rejects the request — the route's `path_parameters` aren't populated when `current_user` is evaluated in this context, causing the RouteMatcher to fail the action check. This extracts API credentials from the feed URL query string and sends them as `Api-Key` / `Api-Username` headers instead. Header-based API authentication doesn't go through `api_parameter_allowed?` and works reliably regardless of route matching state. Also adds warn-level logging throughout the feed fetching pipeline: HTTP failures now log the status code, empty/unparseable responses are surfaced, and RSS parse errors include the exception message. Previously all of these failed silently, making diagnosis require console access. |
||
|---|---|---|
| .. | ||
| poll_all_feeds_spec.rb | ||
| poll_feed_spec.rb | ||