![]() | Wikipedia Help NA‑class Mid‑importance | |||||||||
|
Since people are probably going to ask about this:
The best way (for logged in users) to handle links when on the secure server is to use a JavaScript that automatically converts all non-secure links to secure links. One user has made such a script. I tested it and it works very well. I have asked him if we can add documentation to his script and then recommend the script on this page. He hasn't answered yet, since he hasn't been logged in for some days.
--David Göthberg (talk) 15:22, 3 December 2009 (UTC)
I am not a technologically sophisticated user but I have often wondered about the secure server. This article answered my general questions about it. Regards, —mattisse (Talk) 16:14, 3 December 2009 (UTC)
Currently most links to other Wikimedia projects (like Wiktionary) point to the normal insecure servers, even when the user is using the secure server.
I am now updating the links in the MediaWiki interface and in other places such as the Main Page and the sister project templates. I make it so users on the secure server see secure links, while users on the normal servers see normal links. When doing this I mostly use the ((sec link auto)) template, but in some rare cases I have to hand code the links.
This will not cause any visible change for users on the normal servers, but will be a great improvement for the users on the secure server. To see the difference, take a look at the bottom of the Main Page as seen from the normal servers, and from the secure server
Users of the secure server currently expects any sister project links to be insecure so to make the change visible I let the secure link padlock show wherever I add secure links. When we have updated most of the system messages and some weeks have passed we can hide the padlocks, if we find the padlocks disturbing. But only users on the secure server see the padlocks, and I think they like seeing them (I do!).
See also the related discussions about the change from the old yellow padlock to the new blue padlock and about the update of the Wikipedia Main Page.
The developers have been asked to fix the sister project links in the MediaWiki software, see bugzilla:5440. But they probably will not fix that in a long time, so that's why I am fixing the links here instead.
-David Göthberg (talk) 22:38, 23 December 2009 (UTC)
This sounds great! Why can't we make the log in screen secure by default? Antimatter31 (talk) 13:12, 23 May 2010 (UTC)
(Comment moved to Talk:Terrytoons. Regards, HaeB (talk) 23:26, 30 July 2010 (UTC))
If you are in Wikibooks and you type, say, 'w:Wikipedia:Secure server' in the search box, you arrive at the normal server. Kayau Voting IS evil 10:28, 9 August 2010 (UTC)
Rollback takes you to a strange place with the message that there is no such wiki yet. At least that's the case on en.wikibooks. Kayau Voting IS evil 06:24, 20 August 2010 (UTC)
There is a problem with clicking on other users' userpages in Special:RatingHistory in wikis which use the reader feedback thing. Kayau Voting IS evil C U NEXT YEAR 06:18, 25 August 2010 (UTC)
I would be interested in logging on to Wikipedia securely (so nobody can eavesdrop my password), but using an unencrypted connection after that. Is this supported at all? It seems like the two different sites are completely separate, so logging into and out of one doesn't affect the other. I would use secure all of the time, but sometimes search engines redirect me to the unencrypted pages. How do other people deal with this situation? Bryan Burgers (talk) 13:06, 3 September 2010 (UTC)
Currently, all TOR users, myself, and http://www.downornot.com/secure.wikimedia.org agrees that secure.wikimedia.org is down. I assume this wikipedia site is currently down. Can someone please write that up under this article to inquire its status or contact the Wikipedia webmaster? —Preceding unsigned comment added by Johndoe32102002 (talk • contribs) 04:50, 25 October 2010 (UTC)
Currently (25 October 2010, 4:36 GMT) https://secure.wikimedia.org is back up again. —Preceding unsigned comment added by Johndoe32102002 (talk • contribs) /Aeorisdisc → 20:10, 25 October 2010 (UTC)
The page says, "Some browsers may produce security warnings—ignore them."
This, unfortunately, is extremely bad advice. A common (and commonly ignored) security warning is that the site certificate isn't signed by a root cert known to the browser: this is either because the site admins actually didn't get a proper certificate or, when they did (as in the case of Wikipedia) the user is currently being subject to a man-in-the-middle attack. There is currenly software in the wild to do this. (Drop a message on my talk page if you want references and I'll dig them up.)
The advice really should be to ignore only specific error messages. — Preceding unsigned comment added by Cjs (talk • contribs) 17:30, 13 February 2011 (UTC)
Please help in updating our scripts to no longer use secure.wikimedia.org work-arounds and use protocol-relative urls to Wikimedia domains (i.e. //upload.wikimedia.org
instead of http://upload.wikimedia.org
.
Thanks, Krinkle (talk) 20:36, 3 October 2011 (UTC)
Wikipedia needs to develop a policy regarding external URL links with SSL support.
For example, can Google search engine URL on the Google Wikipedia page use https://www.google.com instead of http://www.google.com?
On some of the pages, such as Google, the links have already been converted to SSL. Some pages, such as Cisco support SSL but have not been converted to SSL.
There should be a consistent policy regarding adding external SSL support. Please chime in with comments or concerns. 64.128.27.82 (talk) 16:56, 20 August 2012 (UTC)
quote: "The old secure server ... https://secure.wikimedia.org/wikipedia/en/wiki/ ... as from 14 November 2012 has been a redirect to http://en.wikipedia.org/wiki/"
This breaks browser security settings and username/password storage settings (both of which which are normally done by domain name) and should have been flagged up on all user pages from the moment that wikimedia.org was deprecated (which apparently happened a year ago yet I was only just told about it a few minutes ago!! Why did no-one tell us poor wikipedia editors who slave away over a hot keyboard?)! Samatarou (talk) 03:56, 17 November 2012 (UTC)
"Some companies, schools and ISPs have proxy servers that meddle with the connection between your browser and Wikipedia. This can make editing impossible. Connecting through the old secure server can bypass such proxies."
The internet is NOT yours, its the company/schools/ISPs. If they block Wikipedia editing, then you shouldnt circumvent it using HTTPS. This is the same as using HTTPS Facebook at work to get around a block.
That sentence on the wiki should be removed. — Preceding unsigned comment added by 69.196.171.151 (talk) 15:16, 17 February 2013
As https is a huge resource sucker and completely unnecessary for wikipedia, there should be instructions on how to turn this setting off. Kremmen (talk) 14:40, 28 March 2014 (UTC)
There is a proposal to enable HTTPS by default for all readers on Wikipedia at the Village Pump. Your input in the discussion would be welcome. Thank you, Tony Tan98 · talk 19:55, 21 February 2015 (UTC)
Should this article list the protocols and ciphers settings for the https server, and whether it uses a properly signed certificate or just the default? These would be nice to know. Thanks. Praemonitus (talk) 17:55, 30 March 2015 (UTC)
At Template_talk:Infobox_medical_condition#Please_consider_HTTPS_for_the_OMIM.2C_MedlinePlus.2C_and_GeneReviews_links Elegie proposes that certain external links make secure referrals. The links being discussed there are used thousands of times in thousands of health articles.
I was wondering if using secure links should be a default recommendation on English Wikipedia, especially considering that now by default Wikipedia itself uses HTTPS. Thoughts from others? Blue Rasberry (talk) 13:42, 16 May 2016 (UTC)
I wish to connect to Wikipedia via plain, unsecured HTTP in Firefox for a single short test (temporarily; my general use will always be via HTTPS) so that I can test if the filter I'm stuck under will allow the mathematical page Tits group, or if it's too broad, blocking the page for the unfortunate (from some points of view) name collision.
However, I can't seem to force a connection- even after logging out and disabling HTTPS Everywhere, I could not coax the page to load in HTTP (by removing the 's' 'https' in the URL bar)- not even by changing my User Agent to something that shouldn't support HTTPS. Help?
...it just occurred to me as I was writing this I can use the requests
python library, which wouldn't even use HTTPS if I wanted it to. So my question no longer applies to me, I guess, but I'd still like an answer- to know if it's something on my end or on the server side. Hppavilion1 (talk) 21:36, 25 September 2017 (UTC)
requests
library, and that it had the expected result (the page was blocked). So it's possible to connect HTTP-only, even if browsers and/or server-side components make things difficult. Hppavilion1 (talk) 00:38, 26 September 2017 (UTC)