Getting the IP ranges documented is a great first step -- thanks, @taavi ! @KCVelaga_WMF -- this step might be useful for your current API traffic analysis work, especially if anything differs from the values you're already using.

Updating priority to low. Flow is a deprecated/unsupported extension, on the path for removal: https://phabricator.wikimedia.org/T332022

Given the reduced frequency and low impact to users (likely fixed by a retry) we're updating the priority to low.

Reassigning to CScott (randomly selected from listed CTT subscribers; feel free to reassign @MSantos or @SLopes-WMF ), given the schedule.

Fun fact, we actually already have a ticket for the sitemap spec clean up too: https://phabricator.wikimedia.org/T402691

For the time being, we should decouple the path considerations from the modules as much as possible. Eventually we will take the audience approach (perhaps not with the specific proposed implementation, but definitely in spirit) with pathing and access, but for now, let's focus on what we're doing with the modules and specs specifically.

Moving to Radar for MWI, since Kamil is taking lead.

CTT is on top of this; moving to radar for MWI

Just noting that we met with SRE, and the "x-trusted-request" categorization header is officially available! Docs here: https://wikitech.wikimedia.org/wiki/CDN/Backend_api#x-trusted-request

Notes from Estimation:

• Create a new module for authentication/token handling, where this is the first endpoint. (noting that CSRF is not actually auth, so we should chat about what to name said module. Maybe 'Access'?)
• Future enhancements may also surface OAuth token handling more elegantly.
• Implementation notes:
  • Recommend doing an investigation of what the actual behavior is within the Action API; consider if we should rebuild/replicate that in MW REST independently of the Action API, with a consideration for the risk of divergence in behavior.
  • We can directly wrap the Action API endpoint. There is an existing pattern and handler for wrapping Action API endpoints, so it is not new, but perhaps less than ideal.

Notes from Estimation:

• The implementor will decide between options 1, 2, and 3.
• We expect the implementor to weigh pros and cons between approaches as part of the decision, and how it might influence initial effort, maintainability, long term architecture, etc. For example, Middleware approach may only make sense if we are going in that direction more holistically/intend to use a middleware pattern for other use cases.

Notes from Estimation:

• Should we consider coming from the other direction? Everything is opted in for spec generation, but have specific flags for where it should appear (Public/Sandbox, Discovery).
• There will be cases where we want specs generated and discoverable but not visible in the sandbox, others where we want them to appear in neither the sandbox nor discovery endpoint.
  • Discoverable but not present in the Sandbox is already supported -- APIs have to be registered for the Sandbox separately.
• There may also be needs where we want different behavior on different wikis; therefore, some additional config as well.
• Possible approach for using module types instead of flags:
  • Public --> Discoverable + Sandbox
  • Internal --> Discoverable, not in sandbox
  • Private --> Neither discoverable nor in sandbox
  • Beta
• Module up vs generator down -- Spec generation currently happens in the handler. We are exploring possibilities for refactoring spec generation as a separate process. Module definition process is probably the right place for this, to keep settings self-contained?
• How we present the options to developers and how the code works are separate concerns.

When you say config, do you mean something set in the overall MediaWiki config? My one hesitation with that is it distributes the logic for API module owners. As someone registering an API, I would want the settings to be as self-contained and discoverable as possible. I do see the argument for keeping config for displaying full module types (like beta/experimental) in the global config, but it seems a little strange to separate it out for a module preference that may be set by the module creator.

Note from review: We should consider testing. When running tests, there should be an option to bypass the suppression flag, so that a spec is still generated and can be used for testing purposes.

Question about:

When authenticating with cookies, all cookies use the Secure flag already, so a reasonable client would not send them over HTTP.

Does that suggest that an unreasonable client might send them over HTTP? Is that happening? What happens if it does?

Adding this capability seems like something the Platform team should own, since it is an auth specific feature. MWI is responsible for API infrastructure rather than specific endpoint behavior.

If this is the only gadget using it, I have minimal concerns about removing it. I suggest that we announce the change is coming and give it a soak period of a week or two before actually removing it, though. Based on the description (and the fact that the gadget calling it has seemingly been broken for a while, haha), it doesn't seem like it is terribly urgent.

Thanks for the additional deep dive, @tstarling . From my perspective, your initial approach of leveraging $wgContentNamespaces and $wgNamespacesToBeSearchedDefault seems reasonable, even though it does not include all of the 1k+ additional namespaces. My assumption is that those lists could be surfaced by default, then could be updated per wiki project or community to include additional content namespaces without the need to make additional changes to this endpoint. They could/would also be included through the 'custom' parameter in the meantime. The only exception would be if there are cases where some of your additional findings should be universally excluded, like Draft. None of the ones in your list really stand out as being problematic to offer in some capacity though, even if they are not intended as public content.

Updated with a bit more detail, following some conversations earlier this week with Bill & SRE.

Duplicate of: https://phabricator.wikimedia.org/T398407