Remove deprecated params from AuthorizePredicate#590
Conversation
The third and fourth parameters of `AuthorizePredicate` and `ObjectAuthorizePredicate` (`signedKey` and `signedKeyOwner`) were deprecated in Fedify 1.5.0 in favor of `RequestContext.getSignedKey()` and `RequestContext.getSignedKeyOwner()`. They were not removed in the Fedify 2.0.0 release as intended, which constitutes a bug: the internal handler code was eagerly calling `getSignedKeyOwner()` before invoking every authorize predicate, causing uncaught `FetchError` exceptions (and HTTP 500 responses) when the remote server requires authorized fetch and returns 401 for the key-owner lookup. This commit removes the two parameters from both callback types and strips the corresponding `getSignedKey()`/`getSignedKeyOwner()` calls and deprecation-warning clone logic from `handleActor()`, `handleObject()`, `handleCollection()`, and `authIfNeeded()`. Predicates that need the signed key or key owner should now call `ctx.getSignedKey()` and `ctx.getSignedKeyOwner()` directly. Tests and the collections documentation example have been updated accordingly. fedify-dev#473 Co-Authored-By: Claude <claude@anthropic.com>
Summary of ChangesHello @dahlia, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request addresses a practical bug and refines the API by removing previously deprecated parameters from authorization predicates. By eliminating the eager fetching of signed keys and their owners, the change prevents unnecessary unauthenticated HTTP requests that could lead to server errors. This simplifies the predicate interfaces and ensures that key owner information is only retrieved when explicitly requested by the predicate, improving robustness and adherence to API design principles. Highlights
Changelog
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request removes the deprecated signedKey and signedKeyOwner parameters from AuthorizePredicate and ObjectAuthorizePredicate. This addresses a bug caused by the eager fetching of signedKeyOwner, which could lead to unnecessary network requests and errors. The changes are applied consistently to the type definitions, internal handlers, tests, and documentation, resolving the issue as described.
Codecov Report✅ All modified and coverable lines are covered by tests.
🚀 New features to boost your workflow:
|
Summary
AuthorizePredicateandObjectAuthorizePredicateacceptedsignedKeyandsignedKeyOwneras third and fourth parameters since Fedify 0.7.0. These were deprecated in Fedify 1.5.0 in favor of callingRequestContext.getSignedKey()andRequestContext.getSignedKeyOwner()directly inside the predicate. They were intended to be removed in Fedify 2.0.0 but were mistakenly left in.This omission caused a practical bug: the internal handler code (
handleActor(),handleObject(),handleCollection(),authIfNeeded()) eagerly calledgetSignedKeyOwner()before every authorize predicate invocation, even when the predicate didn't use the value at all. SincegetSignedKeyOwner()makes an unauthenticated HTTP request to fetch the remote key owner actor, this would throw an uncaughtFetchError(and produce a500 Internal Server Error) whenever the remote server has authorized fetch enabled and returns HTTP 401—as is the case with GoToSocial.Changes
signedKeyandsignedKeyOwnerfromAuthorizePredicateandObjectAuthorizePredicatecallback types.CryptographicKeyimport from callback.ts (no longer referenced).getSignedKey()/getSignedKeyOwner()calls and all associated deprecation-warningclone()logic fromhandleActor(),handleObject(),handleCollection(), andauthIfNeeded().ctx.getSignedKey()/ctx.getSignedKeyOwner()directly.Migration
Predicates that relied on the third and fourth parameters should now call
ctx.getSignedKey()andctx.getSignedKeyOwner()explicitly:Fixes #473