https://freegeoip.net/ has gone out of service and the default setting gets a 403 error of this request. A reasonable default setting should be considered.
A temporary solution is
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Drop support for discontinued freegeoip.net | mediawiki/extensions/UniversalLanguageSelector | master | +4 -7 |
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Invalid | None | T201751 Freegeoip.net service is shutdown | |||
| Resolved | Nikerabbit | T199106 wgULSGeoService and https://freegeoip.net/ out of service |
Can you please explain what is exactly happening?
Has it already stopped working? I think that I still see geolocation working on Wikipedia, and I'm pretty sure that it's not from a cookie, but I might be wrong.
Where will the failure happen?
In ULS we mostly use it on the client-side with window.Geo.
On Local setup, this produce console error as:
Failed to load resource: the server responded with a status of 403 ()
No other issues observed.
if it is set to $wgULSGeoService=true; I get “only” in the JavaScript console an 403 Error. Nevertheless the extension works.
Since the free service is gone, I think we should do the following:
I'm suggesting a Normal priority given this causes errors in development console and those can confuse people to think ULS is broken or that this is related to some other unrelated breakage.
This breaks all wikis using the ULS (most of them). Pages refuse to load, saying that an attempt was made to load an unsecured script over HTTP (even if it was requested by HTTPS): FreeGeoIP in fact redirects the HTTPS requests to an HTTP-only error page.
As this cans cause a whole wiki to get broekn in a secure browser, you should provide a default catcheer that will detect such redirects from HTTPS to HTTP and will not break the browser by trying to follow the redirect for the error returned (JSON) insterad of the actual result. Actually no script part of MediaWiki should tolerate such unsafe redirects to another site or protocol, unless it is specifically configured to allow it.
ULS should then provide the safe checking.
For now users can only disable ULS in their preferences (if they are conencted) but unauthenticated users cannot do that as ULS is enabled by default for them (and these are the users that are also the most likely for whom FreeGeoIP is used to provide some default language settings, which makes only sense or multingual wikis (Commons, Meta, OSM...) but not Wikipedia or Wiktionnary for example, for which the default is the language edition itself and GeoIP should not even be used to tune up the default settings for ULS.
And if users are connected, this GeoIP request should not even be needed (users can set their own prefered language in their own user settings). In Wikimedia, all wikis can also use the default from the global user account on their home wiki where they have registered an account with local languager preferences.
It seems translatewiki.net is using freegeoip. Unfortunally the shutdown message is loaded from http:// resutling in a warning in the browser
The latest firefox and chrome browser flags any secure wiki site using this as insecure and stops script execution because freegeoip's shutdown notice is on http. It might be a good idea to bump the priority of fixing this.
There is no fix per se, given the service is gone. As a workaround you can disable the lookup as described in the task description. We will disable it by default before next MLEB release.
Change 458703 had a related patch set uploaded (by Nikerabbit; owner: Nikerabbit):
[mediawiki/extensions/UniversalLanguageSelector@master] Drop support for discontinued freegeoip.net
Anyway this bug may reoccur at any time: I really suggest that any script or extension that makes HTTPS requests to any third party site does NOT honor any 403 redirect to HTTP, but instead logs a warning to disable it, or treat that redirect as a server-side error (as if it was HTTP 500, and not HTTP 403). This will then allow scripts to behave correctly and not bypass the security.
I wonder if there's a way to handle that a generic way in a common library used by all extensions.
This will make them safer: the status can be kept as 403, instead of being replaced by the status of the redirected page. The library loading the resource should still flag the resource as being in error. The HTTP status text may be kept, but appended by " (error: redirect from HTTPS to HTTP forbidden)". May be some scripts/extension may need to avoid this and a flag could by this check and still honor it, but the HTTP status text should be appended by " (warning: deprecated redirect from HTTPS to HTTP)".
Change 458703 merged by Krinkle:
[mediawiki/extensions/UniversalLanguageSelector@master] Drop support for discontinued freegeoip.net
Since patch was merged, I'm moving this to QA. To test (must be tested outside WMF production): there should be no errors in the development console about freegeoip.net and no requests to that domain should be made. Also, location based stuff (suggested languages) are not working.
Was there also a patch in the code that supported the query of external queries via any web API (independantly of the external service) so that they won't honor any further redirect from HTTPS to HTTP ? This is still needed for security, and may affect other Mediawiki extensions: such redirects should not be followed at all by default (except with a specific authorisation in the module/extension using that external HTTPS API, using an optional parameter to the support library); the global setting specific for $wgULSGeoService is not enough as the problem is more general and we shouldn't need to multiply such global setting when each extension should have its own settings.
@Verdy_p That has nothing to do with this task. In addition browsers seems to already block such requests and it is not possible to detect or prevent those redirects from client side code.
"Browsers seem" is not sufficient. The actual bug is open in specifications of CORS and XMLHttpRequest and there are headers to control this. But this requires developing a javascript library. So yes the bug can (and should) be resolved. Various bugs are also open in browser development to better control this. There are lot of malicious attacks using these redirects and lot of demands to control and avoid pesky redirects which are unsafe, and still maintain a website usable without causing exceptions like those caused here.