Page MenuHomePhabricator

shop.wikimedia.org should be HTTPS only
Closed, ResolvedPublic

Description

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

Details

Reference
bz37790

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 12:26 AM
bzimport added a project: Wikimedia-Shop.
bzimport set Reference to bz37790.

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:

[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

Ejegg added a comment.Jul 18 2014, 5:35 PM

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:

(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)

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.

Ejegg added a comment.Aug 14 2014, 3:54 AM

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.

Ejegg added a comment.Aug 15 2014, 7:45 PM

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/ .

Ejegg added a comment.Sep 24 2014, 9:48 PM

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.

Dzahn added a subscriber: Dzahn.Mar 13 2015, 11:58 PM

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?

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/ .

@Chmarkine was that a duplicate of T63528?

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/ .

@Chmarkine was that a duplicate of T63528?

No. My comment here is about an insecure link URL, whereas T63528 is about HTTPS to HTTP redirect.

Chmarkine set Security to None.
Aklapper removed vshchepakina as the assignee of this task.Oct 7 2015, 11:16 AM
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptOct 7 2015, 11:16 AM
Dzahn moved this task from Backlog to Blocked on External on the HTTPS board.Dec 3 2015, 7:33 PM
Meno25 removed a subscriber: Meno25.Feb 8 2016, 7:38 PM
Restricted Application added a project: Operations. · View Herald TranscriptFeb 23 2016, 6:13 PM
Dzahn added a comment.Feb 24 2016, 4:48 AM

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.

I'm not sure if anyone currently at the Store is aware of this task. Adding @Ppena.

@Dzahn are there any hard deadlines on this?

Ppena added a comment.Feb 26 2016, 9:40 PM

@CCogdill_WMF I'm not sure what you mean, I see https throughout the entire flow of the store? Could you confirm?

Dzahn added a comment.EditedFeb 26 2016, 9:55 PM

@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.

MZMcBride closed this task as Resolved.Feb 26 2016, 11:24 PM

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

cool :) that's great