Add -A/--authorized-fetch option to fedify inbox command #527

sij411 · 2026-01-17T14:43:22Z

Summary

Add -A/--authorized-fetch option to fedify inbox command
When enabled, incoming requests without valid HTTP Signatures are rejected with 401 Unauthorized
Useful for testing whether ActivityPub servers correctly sign outgoing requests

Changes

Added -A/--authorized-fetch CLI option to inbox command
Implemented HTTP signature verification using verifyRequest() in the fetch handler
Added documentation in docs/cli.md

Closes #229

🤖 Generated with Claude Code

gemini-code-assist · 2026-01-17T14:43:35Z

Summary of Changes

Hello @sij411, I'm Gemini Code Assist¹! 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 enhances the fedify inbox command-line tool by adding an optional authorized fetch mode. When enabled, the inbox server will enforce HTTP signature verification on all incoming requests, rejecting those that are unsigned or have invalid signatures. This provides a valuable testing utility for developers working with ActivityPub implementations, allowing them to confirm that their servers are correctly signing outgoing requests as required by many fediverse platforms.

Highlights

New CLI Option: Introduced the -A/--authorized-fetch option to the fedify inbox command, enabling a mode where incoming requests require valid HTTP signatures.
HTTP Signature Verification: Implemented HTTP signature verification for requests received by the fedify inbox server when the authorized fetch mode is active. Requests without valid signatures are rejected with a 401 Unauthorized status.
Testing Utility: This feature is designed to assist in testing ActivityPub servers to ensure they correctly sign their outgoing requests, which is crucial for interoperability with secure fediverse instances.
Documentation Update: Added comprehensive documentation for the new -A/--authorized-fetch option in docs/cli.md, explaining its functionality and use cases.

Using Gemini Code Assist

The 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 /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	`/gemini review`	Performs a code review for the current pull request in its current state.
Pull Request Summary	`/gemini summary`	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	`/gemini help`	Displays a list of available commands.

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 .gemini/ folder in the base of the repository. Detailed instructions can be found here.

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.

Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

sij411 · 2026-01-17T14:44:26Z

/gemini review

gemini-code-assist

Code Review

This pull request introduces a new --authorized-fetch (-A) option to the fedify inbox command. This feature is useful for testing ActivityPub server implementations by enforcing that all incoming requests are signed with valid HTTP Signatures, rejecting unsigned or invalid ones with a 401 Unauthorized status. The implementation is straightforward, adding the CLI option and integrating verifyRequest into the fetch handler. The documentation has also been updated accordingly.

My review found a minor issue with the clarity of the CLI option's description, and I've provided a suggestion to improve it. Overall, this is a valuable addition for developers working with Fedify.

gemini-code-assist · 2026-01-17T14:44:45Z

packages/cli/src/inbox.tsx

+        "--authorized-fetch",
+        {
+          description:
+            message`Enable authorized fetch mode. Incoming requests without valid HTTP signatures with 401 Unauthorized will be rejected.`,


The description for the --authorized-fetch option is slightly confusing. It could be rephrased for better clarity. The current phrasing "Incoming requests without valid HTTP signatures with 401 Unauthorized will be rejected" could be misinterpreted. A clearer phrasing would be "Incoming requests without valid HTTP signatures will be rejected with 401 Unauthorized."

message`Enable authorized fetch mode. Incoming requests without valid HTTP signatures will be rejected with 401 Unauthorized.`,

gemini-code-assist

Code Review

This pull request adds a useful --authorized-fetch option to the fedify inbox command for testing signed requests. The implementation is mostly correct, but there are a couple of areas for improvement.

First, the description for the new CLI option is slightly ambiguous and could be rephrased for better clarity.

More importantly, there's a performance issue where HTTP signatures are verified twice for each request when the new option is enabled. This happens once in the new logic and again within the federation.fetch() call. I've suggested a couple of ways to address this to avoid the redundant work.

Overall, a great addition for improving the testing capabilities of the CLI.

gemini-code-assist · 2026-01-17T14:47:34Z

packages/cli/src/inbox.tsx

+    if (authorizedFetchEnabled) {
+      const key = await verifyRequest(request, {
+        documentLoader: federationDocumentLoader,
+      });
+      if (key == null) {
+        logger.error(
+          "Unauthorized request: HTTP Signature verification failed for {method} {path}",
+          { method: request.method, path: pathname },
+        );
+        return new Response("Unauthorized: Invalid or missing HTTP signature", {
+          status: 401,
+          headers: { "Content-Type": "text/plain; charset=utf-8" },
+        });
+      }
+      logger.debug("HTTP Signature verified: {keyId}", { keyId: key.id?.href });
+    }


This implementation introduces a performance issue due to double verification of HTTP signatures. The verifyRequest call here performs the first verification. However, the subsequent call to federation.fetch() will trigger another verification inside its handleInbox logic because the federation object is configured with skipSignatureVerification: false by default. This is inefficient as it can lead to redundant network requests for public keys.

To fix this, you could either:

(Recommended) Refactor inbox.tsx to create the federation object inside runInbox, allowing you to set skipSignatureVerification: !command.authorizedFetch. This would make the manual verification here unnecessary, as the framework would handle it.

(Workaround) Temporarily set (federation as any).skipSignatureVerification = true; after a successful manual verification and reset it in a finally block around the federation.fetch() call. This is less ideal as it relies on internal properties.

Fair enough

@dahlia Hi, I need your opinion on this!

gemini-code-assist · 2026-01-17T14:47:34Z

packages/cli/src/inbox.tsx

+        "--authorized-fetch",
+        {
+          description:
+            message`Enable authorized fetch mode. Incoming requests without valid HTTP signatures with 401 Unauthorized will be rejected.`,


The current wording of the description is a bit ambiguous and could be misinterpreted. For better clarity, I suggest rephrasing it to make it clear that the requests are rejected with a 401 status.

message`Enable authorized fetch mode. Incoming requests without valid HTTP signatures will be rejected with 401 Unauthorized.`,

codecov · 2026-01-17T14:53:01Z

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ All tests successful. No failed tests found.

🚀 New features to boost your workflow:

📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

Add -A/--authorized-fetch option to fedify inbox command

19279a9

issues-auto-labeler bot added component/cli CLI tools related component/federation Federation object related component/inbox Inbox related component/signatures OIP or HTTP/LD Signatures related labels Jan 17, 2026

Merge branch 'main' into feat/inbox-auth

f9f8ad2

gemini-code-assist bot reviewed Jan 17, 2026

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

Add -A/--authorized-fetch option to fedify inbox command #527

Add -A/--authorized-fetch option to fedify inbox command #527

Uh oh!

sij411 commented Jan 17, 2026 •

edited

Loading

Uh oh!

gemini-code-assist bot commented Jan 17, 2026

Uh oh!

sij411 commented Jan 17, 2026

Uh oh!

gemini-code-assist bot left a comment

Uh oh!

gemini-code-assist bot Jan 17, 2026

Uh oh!

gemini-code-assist bot left a comment

Uh oh!

gemini-code-assist bot Jan 17, 2026

Uh oh!

sij411 Jan 17, 2026

Uh oh!

sij411 Jan 17, 2026

Uh oh!

gemini-code-assist bot Jan 17, 2026

Uh oh!

codecov bot commented Jan 17, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Add -A/--authorized-fetch option to fedify inbox command #527

Are you sure you want to change the base?

Add -A/--authorized-fetch option to fedify inbox command #527

Uh oh!

Conversation

sij411 commented Jan 17, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Changes

Uh oh!

gemini-code-assist bot commented Jan 17, 2026

Summary of Changes

Highlights

Footnotes

Uh oh!

sij411 commented Jan 17, 2026

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist bot Jan 17, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot left a comment

Choose a reason for hiding this comment

Code Review

Uh oh!

gemini-code-assist bot Jan 17, 2026

Choose a reason for hiding this comment

Uh oh!

sij411 Jan 17, 2026

Choose a reason for hiding this comment

Uh oh!

sij411 Jan 17, 2026

Choose a reason for hiding this comment

Uh oh!

gemini-code-assist bot Jan 17, 2026

Choose a reason for hiding this comment

Uh oh!

codecov bot commented Jan 17, 2026

Codecov Report

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

sij411 commented Jan 17, 2026 •

edited

Loading