CORS

[evanp]

"As a Web client developer, I want to have reliable expectations for CORS for the ActivityPub API, so that I can use API endpoints from the browser without going through a proxy server."

This is one of the hard parts of working with the API right now.

[evanp]

There are two cases here, I think:

• A user making authenticated requests to their home server. For example, a user with an OAuth 2.0 bearer token requesting their inbox collection. This seems like a basic necessity for browser-based apps.
• A user making unauthenticated requests to a remote server. It's probably fine if the user has to use the proxyUrl for this kind of request instead.

I don't think CORS is complex enough to represent this reality, though. So, it's probably better to have an open CORS policy, and use a 401 header for all endpoints to indicate that they're not fetchable without authentication (HTTP Signature or OAuth).

[evanp]

This is documented in the basic profile: https://swicg.github.io/activitypub-api/basicprofile#cors

[evanp]

Talking with Mayel about this today. We think at the least we should have a way to access the API when there is an OAuth token in the Authorization header.

[mayel]

Yeah I think we should not use Access-Control-Allow-Origin: * and instead echo back the request's origin, but only when the request is using valid client and/or user authentication:

Access-Control-Allow-Origin: hostname.tld # the origin of the request, but only if we have valid client auth, and it matches the hostname of a valid redirect_uri
Access-Control-Allow-Credentials: true # allows using the Authorization (which is anyway not allowed when using `Access-Control-Allow-Origin: *`)
Vary: Origin # prevents shared caches from incorrectly serving CORS responses to other origins
Access-Control-Allow-Methods: GET, POST