[Bug 40679] $wgServer with protocol causes HTTP links in HTTPS
https://bugzilla.wikimedia.org/show_bug.cgi?id=40679 --- Comment #14 from Krinkle krinklem...@gmail.com 2012-10-02 06:35:13 UTC --- (In reply to comment #13) My general feeling is that whenever $wgServer is mentioned (in discussions or in code), it's always a guessing game with its value is. HTTP, HTTPS, protocol-relative? And this guessing game has a cost. An alternative approach is to be explicit in the variable name itself, so that there's less ambiguity. I don't see the problem here. $wgServer is a configuration variable to set how MediaWiki should represent self-reference urls. If only HTTP or HTTPS is supported (most common) it is set to one of those. Having a $wgHTTPSServer variable doesn't make sense. What would you set it to if a server only supports HTTP, I guess you'll have to set it to http:// then because the server doesn't have https. And what if both are supported (like on Wikipedia), which does it use in the parser? Neither, because those urls can (and should be) without protocol so that they are relatively interpreted by the browser, because the visitor can be on either http or https. $wgServer indicates what the server supports. http, https or both. And in most cases $wgServer can/should be used as-is (without trying to expand it). And if a server preference is needed, then it can be ran through wfExpandUrl (e.g. for wgSecureLogin it will expand to HTTPS if the server supports that. Obviously if the server doesn't support HTTPS it shouldn't try to link there as it would be a broken link pointing to a server error. And if you don't support HTTPS, well, then it doesn't make sense to enable wgSecureLogin. Either way enabling wgSecureLogin when not supported is harmless afaik, it simply maintains http as it would other wise). Before we get into a very generic discussion, what is the actual bug here? What is the problem? How to reproduce this redirect problem? -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40679] $wgServer with protocol causes HTTP links in HTTPS
https://bugzilla.wikimedia.org/show_bug.cgi?id=40679 Roan Kattouw roan.katt...@gmail.com changed: What|Removed |Added CC||roan.katt...@gmail.com AssignedTo|wikibugs-l@lists.wikimedia. |cste...@wikimedia.org |org | --- Comment #1 from Roan Kattouw roan.katt...@gmail.com 2012-10-01 23:35:40 UTC --- I believe the answer to this is don't set $wgServer to an insecure HTTP URL then. AFAIK the HTTPS code doesn't support $wgServer values with http as the scheme, although the redirect loop is a nasty failure mode. Assigning to Chris because he wrote the HTTPS redirection code. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40679] $wgServer with protocol causes HTTP links in HTTPS
https://bugzilla.wikimedia.org/show_bug.cgi?id=40679 --- Comment #2 from Roan Kattouw roan.katt...@gmail.com 2012-10-01 23:36:29 UTC --- Moreover, doesn't setting $wgServer to an HTTP URL result in HTTP URLs appearing in articles, even when viewing them over HTTPS? -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40679] $wgServer with protocol causes HTTP links in HTTPS
https://bugzilla.wikimedia.org/show_bug.cgi?id=40679 --- Comment #3 from Tyler Romeo tylerro...@gmail.com 2012-10-01 23:37:36 UTC --- (In reply to comment #2) Moreover, doesn't setting $wgServer to an HTTP URL result in HTTP URLs appearing in articles, even when viewing them over HTTPS? This I have not tested, but note that this bug will only occur if wfExpandUrl() is called, meaning if the link is relative (like most link URLs are AFAIK), then it won't be a problem. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40679] $wgServer with protocol causes HTTP links in HTTPS
https://bugzilla.wikimedia.org/show_bug.cgi?id=40679
--- Comment #4 from Roan Kattouw roan.katt...@gmail.com 2012-10-01 23:43:18
UTC ---
(In reply to comment #3)
(In reply to comment #2)
Moreover, doesn't setting $wgServer to an HTTP URL result in HTTP URLs
appearing in articles, even when viewing them over HTTPS?
This I have not tested, but note that this bug will only occur if
wfExpandUrl()
is called, meaning if the link is relative (like most link URLs are AFAIK),
then it won't be a problem.
Sure. But try this (fairly common) code snippet:
[{{fullurl:{{FULLPAGENAME}}|action=editsection=new}} Add a new section to this
page]
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are on the CC list for the bug.
___
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40679] $wgServer with protocol causes HTTP links in HTTPS
https://bugzilla.wikimedia.org/show_bug.cgi?id=40679 --- Comment #5 from Chris Steipp cste...@wikimedia.org 2012-10-02 00:07:43 UTC --- (In reply to comment #2) Moreover, doesn't setting $wgServer to an HTTP URL result in HTTP URLs appearing in articles, even when viewing them over HTTPS? Yes, almost all links to load.php and api.php urls are full urls that start with http://. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40679] $wgServer with protocol causes HTTP links in HTTPS
https://bugzilla.wikimedia.org/show_bug.cgi?id=40679 --- Comment #6 from MZMcBride b...@mzmcbride.com 2012-10-02 02:49:20 UTC --- I guess I'm the only one in favor of killing $wgServer altogether? I think a situation in which you have two variables—$wgHTTPServer and $wgHTTPSServer—in which you explicitly define the secure and non-secure canonical URL versions would be better from a wiki administration perspective and a coding perspective. The protocol-relative magic feels very fragile to me. I'm honestly not quite sure how disruptive trying to kill $wgServer would be, though. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40679] $wgServer with protocol causes HTTP links in HTTPS
https://bugzilla.wikimedia.org/show_bug.cgi?id=40679 Krinkle krinklem...@gmail.com changed: What|Removed |Added CC||krinklem...@gmail.com --- Comment #7 from Krinkle krinklem...@gmail.com 2012-10-02 03:02:21 UTC --- (In reply to comment #6) I guess I'm the only one in favor of killing $wgServer altogether? I think a situation in which you have two variables—$wgHTTPServer and $wgHTTPSServer—in which you explicitly define the secure and non-secure canonical URL versions would be better from a wiki administration perspective and a coding perspective. The protocol-relative magic feels very fragile to me. There is no need to have two variables. Earlier last year (before we started using relative protocols) this is exactly what we had. By default we set $wgServer = 'http://example.org'; and on the secure servers to https. The reason we went for protocol-relative instead is because we now serve pages from the main servers, and we want to share the HTML cache. Having two variables solves nothing but introduces a lot of problems. Because that means you'll have to split the cache in a version where the HTML contains http:// everywhere and one with https://, since that is pointless and a problem already solved by the web, we use protocol-relative urls instead starting with //. The problems we have aren't solved by introducing that, and introducing that pattern is already possible without those 2 variables: $wgServer = isHttps() ? 'http://example.org' : 'https://example.org'; We don't need the other value anyway when in the other request type. Except that we do, which is why we have a canonical protocol for API responses. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40679] $wgServer with protocol causes HTTP links in HTTPS
https://bugzilla.wikimedia.org/show_bug.cgi?id=40679 --- Comment #8 from Roan Kattouw roan.katt...@gmail.com 2012-10-02 03:04:01 UTC --- (In reply to comment #6) I guess I'm the only one in favor of killing $wgServer altogether? I think a situation in which you have two variables—$wgHTTPServer and $wgHTTPSServer—in which you explicitly define the secure and non-secure canonical URL versions would be better from a wiki administration perspective and a coding perspective. The protocol-relative magic feels very fragile to me. Well, you're not the only one in favor of having better configurability for what the HTTP and what the HTTPS URLs should be. Protocol-relative URLs are a useful tool to increase cache effectiveness if the http and the https URLs happen to be identical except for the 's', like on the post-secure.wm.o WMF cluster and presumably in most sane 3rd-party setups that support both HTTP and HTTPS. The way the code currently works that's also the *only* way you'll be able to avoid random cache pollution; if we wanted to support the HTTP and HTTPS URLs being different, work would have to be done to split the parser cache based on secure-ness if the HTTP and HTTPS URLs differ. However, we need to retain the ability to not split the cache and use protocol-relative URLs instead, otherwise WMF's parser cache would double in size. I'm honestly not quite sure how disruptive trying to kill $wgServer would be, though. Very. The reason things are the way they are now is precisely because when I implemented this last year, I tried to make my changes minimally disruptive. And they were quite disruptive still, it took me weeks and involved an extensive tour of the skeletons in our closed :) . Messing around with this more would probably take quite a lot of work to clean up all the various assumptions surrounding $wgServer, wfExpandUrl(), Title::getFullURL(), etc. The way I see it, the only gain to be had here would be that we would support setups where HTTP and HTTPS have different URL patterns (like WMF's setup in the secure.wm.o days). I don't know how common that is; I think most people would want them to be the same when they set up SSL. The only reason that we used a different domain name for HTTPS was because we were running a farm of wikis and hadn't built the required infrastructure to do SSL for all of the domains, with all the load balancing and caching stuff involved. The way we solved that was by having one domain name that pointed to one, non-load-balanced machine which bypassed the HTTP caches :D (this is why secure was slow), obviously that wasn't scalable. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40679] $wgServer with protocol causes HTTP links in HTTPS
https://bugzilla.wikimedia.org/show_bug.cgi?id=40679 --- Comment #9 from Krinkle krinklem...@gmail.com 2012-10-02 03:08:17 UTC --- (In reply to comment #0) When $wgServer has a scheme, i.e., it is not protocol-relative, which happens to be the default, wfExpandUrl( ..., PROTO_HTTPS ) will give an HTTP link. This causes ResourceLoader content to be loaded over an insecure connection. It also causes redirect loops when redirecting to HTTPS using wfExpandUrl. If your server supports HTTPS and redirects HTTP to HTTPS, why set $wgServer to an HTTP protocol? I'd say set it to HTTPS, or protocol-relative if you want to support both. This doesn't make sense.. wfExpandUrl only expands the url, never changes it. If it contains http:// that is left alone, because users tend to set http for a reason, indicating it doesn't support https. Otherwise there is no reason to set it to http. (In reply to comment #5) (In reply to comment #2) Moreover, doesn't setting $wgServer to an HTTP URL result in HTTP URLs appearing in articles, even when viewing them over HTTPS? Yes, almost all links to load.php and api.php urls are full urls that start with http://. That is, if $wgServer is set to a http://server If wgServer is set to a protocol-relative url, then it will (obviously) not do that. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40679] $wgServer with protocol causes HTTP links in HTTPS
https://bugzilla.wikimedia.org/show_bug.cgi?id=40679 --- Comment #10 from Roan Kattouw roan.katt...@gmail.com 2012-10-02 03:20:37 UTC --- (In reply to comment #7) There is no need to have two variables. Except if you want to have different URLs for HTTP and HTTPS, I think that was MZ was after. The problems we have aren't solved by introducing that, and introducing that pattern is already possible without those 2 variables: $wgServer = isHttps() ? 'http://example.org' : 'https://example.org'; We don't need the other value anyway when in the other request type. That doesn't actually work, it causes pollution of the parser cache, see my previous comment. Except that we do, which is why we have a canonical protocol for API responses. To expand on this: we have $wgCanonicalServer, which is a fully-qualified (i.e. with protocol) version of $wgServer that is used when building URLs that will be used outside of the context of an HTTP(S) request, or where using protocol-relative URLs won't work or doesn't make sense for some other reason. The typical examples of this is are URLs in notification e-mails and in the recentchanges IRC feeds. In the API, we resolve protocol-relative URLs using the protocol of the current request, and we split the API Squid cache by protocol for this reason; $wgCanonicalServer only comes into play when dealing with things like the externallinks table (see below). $wgCanonicalServer is used in two different ways: * when building URLs to wiki pages, or expanding URLs like /wiki/Foo , the URL is prefixed with $wgCanonicalServer instead of $wgServer * when we encounter a protocol-relative URL that came from somewhere else (e.g. externallinks table in the API), we use $wgCanonicalServer to decide which protocol to put on it As you might have guessed, $wgCanonicalServer is currently set to http:$wgServer on WMF wikis. I deliberately designed it so it could be switched to https later, that's why it's separate from $wgInternalServer (used for Squid purges, will still need to be http). As for actual plans to switch the canonical protocol to HTTPS, that's a question for Ryan. In the meantime, Chris's cookie-based redirection feature should reduce the annoyance of HTTP links in e-mail notifications, because people that receive these e-mails are usually logged in when they receive them, so they'll automatically be redirected to HTTPS. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40679] $wgServer with protocol causes HTTP links in HTTPS
https://bugzilla.wikimedia.org/show_bug.cgi?id=40679 --- Comment #11 from Tyler Romeo tylerro...@gmail.com 2012-10-02 05:16:56 UTC --- The primary problem right now is that there exists a case where giving PROTO_HTTPS to wfExpandUrl() does not give an HTTPS uri. This is a security vulnerability, as well as the root for possible bugs. So the main question is: why does wfExpandUrl do this, and what will happen if we change it? -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40679] $wgServer with protocol causes HTTP links in HTTPS
https://bugzilla.wikimedia.org/show_bug.cgi?id=40679 --- Comment #12 from Krinkle krinklem...@gmail.com 2012-10-02 05:33:57 UTC --- (In reply to comment #11) The primary problem right now is that there exists a case where giving PROTO_HTTPS to wfExpandUrl() does not give an HTTPS uri. This is a security vulnerability, as well as the root for possible bugs. So the main question is: why does wfExpandUrl do this, and what will happen if we change it? How is that a security vulnerability? wfExpandUrl is by no means a security measure, and PROTO_HTTPS is nowhere documented nor intended to generate https urls. The argument to wfExpandUrl means the preferred protocol if there isn't any, not the protocol that will be used in the url. To put it bluntly, if something relies on it returning on https, then it is plain wrong. If that is the topic of this bug, then afaik we can close this as an invalid bug. Please describe (or show) the code that is passing PROTO_HTTPS to wfExpandUrl. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
[Bug 40679] $wgServer with protocol causes HTTP links in HTTPS
https://bugzilla.wikimedia.org/show_bug.cgi?id=40679 --- Comment #13 from MZMcBride b...@mzmcbride.com 2012-10-02 05:58:15 UTC --- (In reply to comment #10) (In reply to comment #7) There is no need to have two variables. Except if you want to have different URLs for HTTP and HTTPS, I think that was MZ was after. That's one use-case, yes. I think secure.example.com is still fairly common, but I'm personally not too concerned with this. My general feeling is that whenever $wgServer is mentioned (in discussions or in code), it's always a guessing game with its value is. HTTP, HTTPS, protocol-relative? And this guessing game has a cost. An alternative approach is to be explicit in the variable name itself, so that there's less ambiguity. And there seems to be more and more of a reliance (in code) on the principle that http/https will be equivalent, but again, I'm not too concerned with this. As you might have guessed, $wgCanonicalServer is currently set to http:$wgServer on WMF wikis. I deliberately designed it so it could be switched to https later, that's why it's separate from $wgInternalServer (used for Squid purges, will still need to be http). Thank you for explaining this. -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ Wikibugs-l mailing list Wikibugs-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
