| • MZMcBride | |
| Jun 21 2012, 4:43 PM |
| F3433871: Screen Shot 2016-02-26 at 1.39.09 PM.png | |
| Feb 26 2016, 9:40 PM |
| F3433869: Screen Shot 2016-02-26 at 1.36.35 PM.png | |
| Feb 26 2016, 9:40 PM |
Currently https://shop.wikimedia.org doesn't work at all. Ideally http://shop.wikimedia.org would unconditionally redirect to https://shop.wikimedia.org.
Version: unspecified
Severity: major
URL: https://shop.wikimedia.org/
See Also:
https://bugzilla.wikimedia.org/show_bug.cgi?id=61528
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | BBlack | T104681 HTTPS Plans (tracking / high-level info) | |||
| Declined | BCornwall | T128559 Enable HSTS on store.wikimedia.org for HTTPS | |||
| Resolved | None | T39790 shop.wikimedia.org should be HTTPS only | |||
| Resolved | Krinkle | T93959 Shop homepage on HTTPS loads insecure content | |||
| Resolved | Krinkle | T96818 Shop homepage on HTTPS contains insecure submission form |
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:
[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)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.
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.
Did you resolve T63528 by updating that link? Is it the same thing?
No. My comment here is about an insecure link URL, whereas T63528 is about HTTPS to HTTP redirect.
shop.wikimedia.org and shop.wikipedia.org point to our Apache cluster:
templates/wikipedia.org:shop 600 IN DYNA geoip!text-addrs templates/wikimedia.org:shop 600 IN DYNA geoip!text-addrs
but only to redirect to store.
files/apache/sites/redirects.conf: ServerAlias shop.wikimedia.org files/apache/sites/redirects.conf: ServerAlias shop.wikipedia.org files/apache/sites/redirects.conf: ServerAlias shop.wikipedia.com files/apache/sites/redirects.conf: # funnel shop.wikimedia.org //store.wikimedia.org .. files/apache/sites/redirects/redirects.dat:funnel shop.wikipedia.org //store.wikimedia.org
store is external, on shopify.com
templates/wikimedia.org:store 1H IN CNAME c.ssl.shopify.com.
the operations team can't do much here, this is outside our control. so either shopify fixes it or we have to stop outsourcing and run the shop on our own infrastructure.
@CCogdill_WMF I'm not sure what you mean, I see https throughout the entire flow of the store? Could you confirm?
@MZMcBride @Chmarkine can you chime in and show the remaining issues to @Ppena ?
@CCogdill_WMF i don't know of any hard deadlines, it's just that this ticket has been created back in 2012 and still couldn't be fully fixed, as far as i can tell
Hmm good point @Ppena, I haven't actually checked on this since the store was redesigned. I know there used to be an issue with the customer login during checkout, but it looks like that is all https now.
This looks fixed now. Thanks, all!
$ curl -Is "http://shop.wikimedia.org/" | grep Location Location: https://shop.wikimedia.org/
$ curl -Is "https://shop.wikimedia.org/" | grep Location Location: https://store.wikimedia.org/
$ curl -Is "https://store.wikimedia.org/" | head -1 HTTP/1.1 200 OK