Last modified: 2011-11-02 03:38:33 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T34066, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 32066 - Allow HTTPS access on noc.wikimedia
Allow HTTPS access on noc.wikimedia
Status: RESOLVED DUPLICATE of bug 23004
Product: Wikimedia
Classification: Unclassified
SSL related (Other open bugs)
unspecified
All All
: Unprioritized enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
: ops
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-10-31 00:48 UTC by billinghurst
Modified: 2011-11-02 03:38 UTC (History)
5 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description billinghurst 2011-10-31 00:48:15 UTC
I am wondering whether it is by omission or purpose that http://noc.wikimedia.org/ does not have https:// available?
Comment 1 Sam Reed (reedy) 2011-10-31 01:01:26 UTC
Why does it really need it?
Comment 2 billinghurst 2011-10-31 01:27:39 UTC
(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.
Comment 3 billinghurst 2011-10-31 01:29:58 UTC
(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."
Comment 4 Roan Kattouw 2011-10-31 08:43:25 UTC
Was also filed internally last week as RT #1798.
Comment 5 MZMcBride 2011-10-31 08:52:59 UTC
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.
Comment 6 Roan Kattouw 2011-10-31 08:55:21 UTC
(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.
Comment 7 Umherirrender 2011-10-31 16:52:57 UTC
bug 23004
Comment 8 Ryan Lane 2011-10-31 18:04:24 UTC
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.
Comment 9 MZMcBride 2011-11-01 00:57:20 UTC
(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.
Comment 10 Ryan Lane 2011-11-01 00:59:42 UTC
Well, until you or I get time to do such a thing, individual bugs are fine.
Comment 11 MZMcBride 2011-11-02 03:38:33 UTC

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

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links