Change Details

The push notifications service needs to be able to authenticate to MediaWiki in order to clean up subscriptions that are reported by push provider APIs as expired for invalid. As currently implemented, the service is authenticating using the [[ https://www.mediawiki.org/wiki/API:Login#Method_2._clientlogin | action=clientlogin ]] API module and successfully deleting subscriptions when running locally. **Problem** This login strategy currently does not work in the Beta Cluster. [[ https://www.mediawiki.org/wiki/Manual:$wgForceHTTPS | $wgForceHTTPS ]] is configured to `true` for all wikis in InitialiseSettings-labs.php, and as a result, all cookies that MediaWiki provides to clients include the `Secure` attribute. The `Secure` attribute prohibits clients from sending a cookie back over insecure (non-`https`) connections. In the Beta Cluster, we are interacting with a `deployment-mediawiki` instance over a secure connection, and TLS is unavailable. Since the `clientlogin` flow relies on cookies when generating and evaluating CSRF tokens, requests from the service are failing with `badtoken` errors. It is likely that this problem will also prevent authenticating via action=clientlogin in production, since production is configured similarly and the service will likely be interacting with MediaWiki through insecure connections to a service proxy. **Possible solutions** 1) Update the wiki configurations to account for internal clients using cookies $wgForceHTTPS pertains to how external clients may connect to MediaWiki. Forcing the `Secure` attribute on all cookies sent by MediaWiki if $wgForceHTTPS is true does not account for the possibility of internal clients using cookies in their interactions with MediaWiki. We could work with #platform_engineering and others to reevaluate this setting and explore alternative options that better support internal clients. 2) Update the authentication strategy used by the push service According to the docs on mediawiki.org, action=clientlogin is primarily intended to support interactive authentication flows. There may be better authentication options available to clients running internally to the cluster. OAuth is one option worth exploring in particular. The [[ https://www.mediawiki.org/wiki/Extension:OAuth | OAuth ]] extension is running on all wikis in production and on beta and should be able to support OAuth authentication by the push service.

The push notifications service needs to be able to authenticate to MediaWiki in order to clean up subscriptions that are reported by push provider APIs as expired or otherwise invalid. As currently implemented, the service is authenticating using the [[ https://www.mediawiki.org/wiki/API:Login#Method_2._clientlogin | action=clientlogin ]] API module and successfully deleting subscriptions when running locally. **Problem** This login strategy currently does not work in the Beta Cluster. [[ https://www.mediawiki.org/wiki/Manual:$wgForceHTTPS | $wgForceHTTPS ]] is configured to `true` for all wikis in InitialiseSettings-labs.php, and as a result, all cookies that MediaWiki provides to clients include the `Secure` attribute. The `Secure` attribute prohibits clients from sending a cookie back over insecure (non-`https`) connections. In the Beta Cluster, we are interacting with a `deployment-mediawiki` instance over a secure connection, and TLS is unavailable. Since the `clientlogin` flow relies on cookies when generating and evaluating CSRF tokens, requests from the service are failing with `badtoken` errors. It is likely that this problem will also prevent authenticating via action=clientlogin in production, since production is configured similarly and the service will likely be interacting with MediaWiki through insecure connections to a service proxy. **Possible solutions** 1) Update the wiki configurations to account for internal clients using cookies $wgForceHTTPS pertains to how external clients may connect to MediaWiki. Forcing the `Secure` attribute on all cookies sent by MediaWiki if $wgForceHTTPS is true does not account for the possibility of internal clients using cookies in their interactions with MediaWiki. We could work with #platform_engineering and others to reevaluate this setting and explore alternative options that better support internal clients. 2) Update the authentication strategy used by the push service According to the docs on mediawiki.org, action=clientlogin is primarily intended to support interactive authentication flows. There may be better authentication options available to clients running internally to the cluster. OAuth is one option worth exploring in particular. The [[ https://www.mediawiki.org/wiki/Extension:OAuth | OAuth ]] extension is running on all wikis in production and on beta and should be able to support OAuth authentication by the push service.

The push notifications service needs to be able to authenticate to MediaWiki in order to clean up subscriptions that are reported by push provider APIs as expired foror otherwise invalid. As currently implemented, the service is authenticating using the [[ https://www.mediawiki.org/wiki/API:Login#Method_2._clientlogin | action=clientlogin ]] API module and successfully deleting subscriptions when running locally. **Problem** This login strategy currently does not work in the Beta Cluster. [[ https://www.mediawiki.org/wiki/Manual:$wgForceHTTPS | $wgForceHTTPS ]] is configured to `true` for all wikis in InitialiseSettings-labs.php, and as a result, all cookies that MediaWiki provides to clients include the `Secure` attribute. The `Secure` attribute prohibits clients from sending a cookie back over insecure (non-`https`) connections. In the Beta Cluster, we are interacting with a `deployment-mediawiki` instance over a secure connection, and TLS is unavailable. Since the `clientlogin` flow relies on cookies when generating and evaluating CSRF tokens, requests from the service are failing with `badtoken` errors. It is likely that this problem will also prevent authenticating via action=clientlogin in production, since production is configured similarly and the service will likely be interacting with MediaWiki through insecure connections to a service proxy. **Possible solutions** 1) Update the wiki configurations to account for internal clients using cookies $wgForceHTTPS pertains to how external clients may connect to MediaWiki. Forcing the `Secure` attribute on all cookies sent by MediaWiki if $wgForceHTTPS is true does not account for the possibility of internal clients using cookies in their interactions with MediaWiki. We could work with #platform_engineering and others to reevaluate this setting and explore alternative options that better support internal clients. 2) Update the authentication strategy used by the push service According to the docs on mediawiki.org, action=clientlogin is primarily intended to support interactive authentication flows. There may be better authentication options available to clients running internally to the cluster. OAuth is one option worth exploring in particular. The [[ https://www.mediawiki.org/wiki/Extension:OAuth | OAuth ]] extension is running on all wikis in production and on beta and should be able to support OAuth authentication by the push service.