Last modified: 2014-09-24 21:48:26 UTC
Currently <https://shop.wikimedia.org> doesn't work at all. Ideally <http://shop.wikimedia.org> would unconditionally redirect to <https://shop.wikimedia.org>.
This is a security related issue, so highered the importance.
We're working on the https issue because https://shop.wikimedia.org should work (right now it works but throws a mismatched certificate error) . This has taken far longer then we woud like because it required back end changes on the partners side but is, I believe, getting very close and we just approved the certificate. If it isn't in place by the start of next week we will start using https://wikimedia.myshopify.org as a stop gap so that we can provide the security without the warnings and I've already changed it so that login pages will use that url so that they are secure. I'm not certain if the shop itself, like most online shops, necessarily needs to be forced to https for browsing purposes as this seems un necessary and isn't a security issue. The payment pages are and always will be forced to be https.
The HTTPS version of the shop is in place as of today, and does not throw a certificate error for me (although the "Issued To" field shows Shopify Inc. instead of Wikimedia Foundation, Inc.) However, this bug has not been fixed yet; you are still able to visit the shop through the unsecure HTTP protocol. The shop is quite different than the Wikimedia wikis, which only allow browsing through HTTPS; its traffic is probably quite low, so there shouldn't be any technical reasons not to force users to use HTTPS.
There are still some, relatively small, bugs with the https implementation. The main one is that it has a weird bug where if you are trying to log into your account from https and screw up your password it redirects you to http for the retry. I still haven't fixed that one yet. I will see if setting up to force fixes/hurts these issues and will close this if possible. In the mean while we DO force people to checkout via https etc.
(In reply to comment #4) > There are still some, relatively small, bugs with the https implementation. > I will see if setting up to force fixes/hurts these issues and will close > this if possible. In the mean while we DO force people to checkout via > https etc. James: Any updates? Is this ticket still high priority?
Just a quick update here, after seeing bug 61528 (can we merge these two? Not sure of the etiquette here) I've gotten in touch with Shopify and confirmed they *can* make this change, but it's going to take some effort. That's all I know as of today, but we've made this highest priority with Shopify as we recognize there's not way we can expect to further publicize the shop without fixing this bug. Right now our main focus is on what 61528 discusses: the login page. We'll see if any issue remains after that. I'll update once Shopify gives us an ETA, but please know we're actively pushing for this feature.
As an update to my comments from February, after extensive follow-up with Shopify and research on their part, they determined they can't seem to fix this problem on their end. The fr-tech team has been asked to look into this, but understandably their resources are primarily allocated elsewhere. Fundraising is working to move some resources around so that we can get a little more time dedicated to the store and projects like this. I'm sorry I can't give much more information now, but will continue to check in with our tech team to see if they can find a solution.
assigning this to Caitlin for now since I'm no longer involved in the Shop (staying in the CC list since I'm obviously still around and as have time can help where needed)
Hi Everyone! My name is Victoria and I am new Fundraising Associate at Wikimedia that will be working on the Wikimedia shop. This https issue goes back to 2012 and I hope that we finally fixed it! While most pages on Shopify let you edit all of the HTML, the checkout page only lets you use a custom style sheet and translate the text. We used that to remove the link completely. The account login is still on the home page and it's secure. If you see any other instances of http, please let us know! Thank you!
I'm making Victoria the assignee on this bug as she is transitioning into the WMF lead on the Shop. I'll also close this ticket, but please let us know if other http issues arise. Thank you all for reporting this, and thanks Victoria and fundraising tech for the fix!
https://shop.wikimedia.org/ seems ok. or not, now is 502. and now fixed again? some outstanding issues: * make links from pages like https://shop.wikimedia.org/pages/privacy-policy (and other pages like https://shop.wikimedia.org/pages/about-wikimedia ) to WMF wikis or other parts of the shop site use HTTPS (or protorel) * https://shop.wikimedia.org/products/wikipedia-globe-sweats has mixed-content warnings and also probably violates the site's privacy policy (3rd-party cookies that are not really necessary) and when loading the facebook widget passes in a URL as param with HTTP as protocol (not HTTPS)[0] * fonts pulled from google rather than WMF or shopify. (again, possible privacy policy violation? CC luis to look into these parts) * https://shop.wikimedia.org/account/register POSTs to HTTPS and then (if e.g. you submit a blank form or have some other error) sends you a 302 to the cleartext (HTTP) site. [0] Blocked loading mixed active content "http://platform.twitter.com/widgets.js" @ https://shop.wikimedia.org/products/wikipedia-globe-sweats Blocked loading mixed active content "http://assets.pinterest.com/js/pinit.js" @ https://shop.wikimedia.org/products/wikipedia-globe-sweats GET https://www.facebook.com/plugins/like.php?href=http://shop.wikimedia.org/products/wikipedia-globe-sweats&send=false&layout=button_count&width=120&show_faces=false&action=like&colorscheme=light&font&height=21 [HTTP/1.1 200 OK 405ms]
also, the bug is titled "shop.wikimedia.org should be HTTPS only". The bug should be left open until HTTP is no longer supported. (all HTTP requests are redirected to HTTPS. maybe even enable HSTS and HSTS preload) https://en.wikipedia.org/wiki/HTTP_Strict_Transport_Security
This is not possible to fix while the shop is hosted on Shopify. They don't offer the option of turning off http, and in certain places, like their post-login redirect, they automatically send the user to http. Unless we want to find a new vendor or take on the responsibility of hosting our own ecommerce site, this is a WONTFIX.
(In reply to Elliott Eggleston from comment #13) > Unless we want to find a new vendor or take on the responsibility of hosting > our own ecommerce site, this is a WONTFIX. Who could/would make a final decision on this, before this ticket ends dormant? :/
(In reply to Elliott Eggleston from comment #13) > This is not possible to fix while the shop is hosted on Shopify. They don't > offer the option of turning off http, and in certain places, like their > post-login redirect, they automatically send the user to http. Presumably Shopify has an issue tracker of some kind? Is there an open ticket about this issue (i.e., a store cannot be HTTPS-only currently)? > Unless we want to find a new vendor or take on the responsibility of hosting > our own ecommerce site, this is a WONTFIX. This is a bit of a false dichotomy. Let's get Shopify to fix their code. :-) If Shopify really can't support an HTTPS-only site in 2014, then it makes more sense to reëvaluate using them as a vendor than it does to close this ticket. For sure.
(In reply to jeremyb from comment #11) > https://shop.wikimedia.org/ seems ok. or not, now is 502. and now fixed > again? > > some outstanding issues: > > * make links from pages like https://shop.wikimedia.org/pages/privacy-policy > (and other pages like https://shop.wikimedia.org/pages/about-wikimedia ) to > WMF wikis or other parts of the shop site use HTTPS (or protorel) > * https://shop.wikimedia.org/products/wikipedia-globe-sweats has > mixed-content warnings and also probably violates the site's privacy policy > (3rd-party cookies that are not really necessary) and when loading the > facebook widget passes in a URL as param with HTTP as protocol (not HTTPS)[0] > * fonts pulled from google rather than WMF or shopify. (again, possible > privacy policy violation? CC luis to look into these parts) > * https://shop.wikimedia.org/account/register POSTs to HTTPS and then (if > e.g. you submit a blank form or have some other error) sends you a 302 to > the cleartext (HTTP) site. > > [0] > Blocked loading mixed active content > "http://platform.twitter.com/widgets.js" @ > https://shop.wikimedia.org/products/wikipedia-globe-sweats > Blocked loading mixed active content > "http://assets.pinterest.com/js/pinit.js" @ > https://shop.wikimedia.org/products/wikipedia-globe-sweats > GET > https://www.facebook.com/plugins/like.php?href=http://shop.wikimedia.org/ > products/wikipedia-globe- > sweats&send=false&layout=button_count&width=120&show_faces=false&action=like& > colorscheme=light&font&height=21 [HTTP/1.1 200 OK 405ms] Thank you for this post. Elliot/Victoria: if you could take a look at these issues and file tickets and speak to the legal team, that would be great. There are a few discrete issues here all of which should be addressable.
(In reply to MZMcBride from comment #15) > (In reply to Elliott Eggleston from comment #13) > > This is not possible to fix while the shop is hosted on Shopify. They don't > > offer the option of turning off http, and in certain places, like their > > post-login redirect, they automatically send the user to http. > > Presumably Shopify has an issue tracker of some kind? Is there an open > ticket about this issue (i.e., a store cannot be HTTPS-only currently)? As noted in my above comments, we have had an open ticket with Shopify about this since February 2014. Thus far they have been unable to allocate resources for a fix, but we are continuing to ask for help. > > > Unless we want to find a new vendor or take on the responsibility of hosting > > our own ecommerce site, this is a WONTFIX. > > This is a bit of a false dichotomy. Let's get Shopify to fix their code. :-) > If Shopify really can't support an HTTPS-only site in 2014, then it makes > more sense to reëvaluate using them as a vendor than it does to close this > ticket. For sure. This is certainly something we can look into, however with limited resources, the Shop has priorities that weigh heavier than this one, mainly in finding and moving to a new fulfillment partner. We can keep this bug open in the interim, but I just want to manage expectations about timing, as switching to a new vendor would require months of planning and integration.
I fixed what pages I could, making all links https where the destination supports it, and making the one img tag I saw protocol relative. I don't see where the share/like buttons are controlled, but I'll take another look.
OK, found the social media snippets and updated so all are loaded securely and are liking/tweeting/pinning/plusoneing the secure version of the product page.
Is it possible for us to change the "Return to Store" link on https://shop.wikimedia.org/account/login page to https://shop.wikimedia.org? It currently links to http://shop.wikimedia.org/ .
Hi chmarkine@hotmail.com, Thanks for catching that! I updated that link and the matching one on the registration page, and also fixed the 'added to cart' popup link.
