Change Details

== Current state == Short description editing API ([[ https://api.wikimedia.org/wiki/API_reference/Core/Pages/Get_description | GET ]],[[ https://api.wikimedia.org/wiki/API_reference/Core/Pages/Edit_description | PUT ]],[[ https://api.wikimedia.org/wiki/API_reference/Core/Pages/Delete_description | DELETE ]]) was [[ https://github.com/wikimedia/mobileapps/blob/master/routes/page/description.js | implemented in mobileapps ]] service and exposed via API Gateway. Since originally the API was intended to only be accessible via API Gateway, the implementation only supports OAuth2 authentication method. The service [[ https://github.com/wikimedia/mobileapps/blob/c83968486eb6476ed1762249441a010e5aaaf1be/lib/mwapi.js#L393-L398 | passes ]] the `Authorization` header along to mediawiki. Also, since OAuth2 is safe against CSRF, the service [[ https://github.com/wikimedia/mobileapps/blob/c83968486eb6476ed1762249441a010e5aaaf1be/lib/mwapi.js#L400-L411 | short-circuits CSRF token ]] protection for convenience of the clients. API Gateway has OAuth 2 baked into it - non-authenticated requests are only allowed for GET, and they are only allowed for testing purposes, so rate-limited vigorously. Cookies are stripped entirely in both directions. == The problem == WMF mobile apps want to use the new short description API soon, but they can not yet (or will not ever) use OAuth2 for authentication. So, API Gateway APIs are rather useless for them, since they can not authenticate. == Solution options == Without generic strategy on the gateway future (whether we want our internal clients to use it, whether we want our internal clients to switch to OAuth2 or we want to build custom Auth methods into gateway) it's hard to recommend comprehensive (and ultimately correct) path forward. Here's the workaround that in my opinion will be the easiest to implement and make the least amount of damage: 1. Modify mobileapps service that implements the endpoint. Allow passing thrown the cookie, add a 'csfr_token' parameter. If 'Authentication' header is set, token should be optional. 2. Expose the service in RESTBase, passing along the cookie. RESTBase is deprecated, and we've tried to not add anything new to it, but in this case trying to bend API Gateway into supporting multiple authentication model without knowing we would need that in future would make more damage and create more technical debt. 3. Apps already know how to talk to RESTBase, apps will need to implement fetching CSRF token from MW API, but I believe they are already doing that for editing other types of content.

== Current state == Short description editing API ([[ https://api.wikimedia.org/wiki/API_reference/Core/Pages/Get_description | GET ]],[[ https://api.wikimedia.org/wiki/API_reference/Core/Pages/Edit_description | PUT ]],[[ https://api.wikimedia.org/wiki/API_reference/Core/Pages/Delete_description | DELETE ]]) was [[ https://github.com/wikimedia/mobileapps/blob/master/routes/page/description.js | implemented in mobileapps ]] service and exposed via API Gateway. Since originally the API was intended to only be accessible via API Gateway, the implementation only supports OAuth2 authentication method. The service [[ https://github.com/wikimedia/mobileapps/blob/c83968486eb6476ed1762249441a010e5aaaf1be/lib/mwapi.js#L393-L398 | passes ]] the `Authorization` header along to mediawiki. Also, since OAuth2 is safe against CSRF, the service [[ https://github.com/wikimedia/mobileapps/blob/c83968486eb6476ed1762249441a010e5aaaf1be/lib/mwapi.js#L400-L411 | short-circuits CSRF token ]] protection for convenience of the clients. API Gateway has OAuth 2 baked into it - non-authenticated requests are only allowed for GET, and they are only allowed for testing purposes, so rate-limited vigorously. Cookies are stripped entirely in both directions. == The problem == WMF mobile apps want to use the new short description API soon, but they can not yet (or will not ever) use OAuth2 for authentication. So, API Gateway APIs are rather useless for them, since they can not authenticate. == Solution options == Without generic strategy on the gateway future (whether we want our internal clients to use it, whether we want our internal clients to switch to OAuth2 or we want to build custom Auth methods into gateway) it's hard to recommend comprehensive (and ultimately correct) path forward. Here's the workaround that in my opinion will be the easiest to implement and make the least amount of damage: 1. Modify mobileapps service that implements the endpoint. Allow passing thrown the cookie, add a 'csfr_token' parameter. If 'Authentication' header is set, token should be optional. 2. Expose the service in RESTBase, passing along the cookie. RESTBase is deprecated, and we've tried to not add anything new to it, but in this case trying to bend API Gateway into supporting multiple authentication flows without knowing we would need that in future would make more damage and create more technical debt. 3. Apps already know how to talk to RESTBase, apps will need to implement fetching CSRF token from MW API, but I believe they are already doing that for editing other types of content.

== Current state == Short description editing API ([[ https://api.wikimedia.org/wiki/API_reference/Core/Pages/Get_description | GET ]],[[ https://api.wikimedia.org/wiki/API_reference/Core/Pages/Edit_description | PUT ]],[[ https://api.wikimedia.org/wiki/API_reference/Core/Pages/Delete_description | DELETE ]]) was [[ https://github.com/wikimedia/mobileapps/blob/master/routes/page/description.js | implemented in mobileapps ]] service and exposed via API Gateway. Since originally the API was intended to only be accessible via API Gateway, the implementation only supports OAuth2 authentication method. The service [[ https://github.com/wikimedia/mobileapps/blob/c83968486eb6476ed1762249441a010e5aaaf1be/lib/mwapi.js#L393-L398 | passes ]] the `Authorization` header along to mediawiki. Also, since OAuth2 is safe against CSRF, the service [[ https://github.com/wikimedia/mobileapps/blob/c83968486eb6476ed1762249441a010e5aaaf1be/lib/mwapi.js#L400-L411 | short-circuits CSRF token ]] protection for convenience of the clients. API Gateway has OAuth 2 baked into it - non-authenticated requests are only allowed for GET, and they are only allowed for testing purposes, so rate-limited vigorously. Cookies are stripped entirely in both directions. == The problem == WMF mobile apps want to use the new short description API soon, but they can not yet (or will not ever) use OAuth2 for authentication. So, API Gateway APIs are rather useless for them, since they can not authenticate. == Solution options == Without generic strategy on the gateway future (whether we want our internal clients to use it, whether we want our internal clients to switch to OAuth2 or we want to build custom Auth methods into gateway) it's hard to recommend comprehensive (and ultimately correct) path forward. Here's the workaround that in my opinion will be the easiest to implement and make the least amount of damage: 1. Modify mobileapps service that implements the endpoint. Allow passing thrown the cookie, add a 'csfr_token' parameter. If 'Authentication' header is set, token should be optional. 2. Expose the service in RESTBase, passing along the cookie. RESTBase is deprecated, and we've tried to not add anything new to it, but in this case trying to bend API Gateway into supporting multiple authentication modelflows without knowing we would need that in future would make more damage and create more technical debt. 3. Apps already know how to talk to RESTBase, apps will need to implement fetching CSRF token from MW API, but I believe they are already doing that for editing other types of content.