Page MenuHomePhabricator

Allow HTTPS access on noc.wikimedia
Closed, ResolvedPublic

Description

I am wondering whether it is by omission or purpose that http://noc.wikimedia.org/ does not have https:// available?


Version: unspecified
Severity: enhancement

Details

Reference
bz32066

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 12:01 AM
bzimport added projects: HTTPS, acl*sre-team.
bzimport set Reference to bz32066.
bzimport added a subscriber: Unknown Object (MLST).

(In reply to comment #1)

Why does it really need it?

I was about requesting an interwiki link to the server to be added, and I presume that there is a requirement to note or configure relative urls or otherwise. If that is not the case, okay; there is no information about to assist those of us who are clueless.

(In reply to comment #1)

Why does it really need it?

Oh, and I did ask in #wikimedia-tech prior, and it was suggested that I add a request and to let the decision lie with "those who make such decisions."

Was also filed internally last week as RT #1798.

Quickly approaching a https://en.wikipedia.org/wiki/Zero_One_Infinity problem here. Either all *.wikimedia.org domains should support https or none should. Allowing an arbitrary set is a bad idea. History tells us this (similar issues have arisen with *.wikimedia.org login cookies).

Else, perhaps a more systematic approach can be taken? The large underlying motivation to making the wikis support https is that there are user login credentials being passed in headers. For noc.wikimedia.org, it's all public files with no user auth, as far as I know. I'm not sure why it would need https support.

(In reply to comment #5)

Else, perhaps a more systematic approach can be taken? The large underlying
motivation to making the wikis support https is that there are user login
credentials being passed in headers. For noc.wikimedia.org, it's all public
files with no user auth, as far as I know. I'm not sure why it would need https
support.

I believe it's our intention to support HTTPS for all of our domains, but I'll leave the authoritative answer to Ryan.

I don't think it's necessary to have this argument every time a bug is submitted for services that don't have https, so... For every service we have, if it is feasible to do https, we should do https.

Please continue to submit bugs for services which are missing https.

(In reply to comment #8)

Please continue to submit bugs for services which are missing https.

Are you sure individual bugs make sense here? Something more systematic seems saner.

Well, until you or I get time to do such a thing, individual bugs are fine.

  • This bug has been marked as a duplicate of bug 23004 ***