Closed Bug 875231 Opened 11 years ago Closed 11 years ago

Embedding Of Smartsheet Platform Content causes Mixed Content Errors

Categories

(Infrastructure & Operations :: IT-Managed Tools, task)

Product:
Infrastructure & Operations
Component:
IT-Managed Tools
Type:
task
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: freddy, Unassigned)

References

(Blocks 1 open bug,
URL
)

Details

(Keywords: verifyme)

Attachments

(2 files)

smartsheet_push.log
6.56 KB, text/plain
Details
Screen Shot 2013-07-18 at 5.33.57 PM.png
477.07 KB, image/png
Details 
The smartsheet wiki plugin uses http for smartsheet URLs, but the Mozilla Wiki uses HTTPS (and enforces it via Strict Transport Security).

This means that Firefox users will never be able to view the smartsheets.

To make matters worse, it looks like smartsheet does not support HTTPS...they host content on S3 and we get a cert error (wrong domain for cert).
Adding example URL..
URL: https://wiki.mozilla.org/Websites/Sni...
Not sure what we can do on this.

The HSTS header we send is for 6 months... even if we removed the redirect and removed the header, it'd be that long before the problem would go away entirely. But then we have to start worrying about when wikimo *should* be HTTPS... probably at least whenever the user is logged in, but maybe other cases too. Since logins are internal to wikimo (as opposed to Apache-provided Basic Auth, this would likely require some sort of mediawiki extension to do properly. OpSec might have concerns here beyond the basics, too. In any case there are definitely going to be scenarios where you're looking at a page over SSL, which means anything we do on this front is inherently a partial fix.

On the other hand, Smartsheet is a 3rd party service... we have zero control over that. We can easily edit the plugin we use (it was written in-house), but that's not very useful if Firefox will then just block the content for a different reason.


CC'ing Joe S from OpSec, and Ben Sternthal (the author of the plugin) for any thoughts on this. I hate to WONTFIX, but I don't see any good way out of this pickle, unless we can convince Smartsheet to start supporting SSL for this type of connection.
Chris More was in communication with smartsheet about this, however we dont have an eta and honestly given the amazon cert issue this may not be fully resolved.

However I propose the following solution!

Each smartsheet (when published can have 2 urls):

1. Read Only HTML (We currently Use This one)
http://publish.smartsheet.com/21569255f4fb4ccb91ea6cf16683c16c

2. Read Only Full
https://www.smartsheet.com/b/publish?EQBCT=355f3fbc546c441e8bb02955be648bc6

So the second URL looks to support HTTPS and does not have the CERT error. The only downside is you get some extra UI elements that don't do anything (it's still read only).

My recommendation would be to go with #2, if you all agree I am happy to update the plugin.
(In reply to Frederik Braun [:freddyb] from comment #1)
> Adding example URL..

In the example, I don't see the mixed content warning (probably because I Don't have the smartsheet wiki plugin installed).  If I did have the plugin installed, the wiki page (https://wiki.mozilla.org/Websites/Snippets/Rewrite#Timeline) would have an <iframe src=http://publish.smartsheet.com/6d80ffeae4be4a849b6f66c30fd1e178> - is that correct?
(In reply to Ben (:bensternthal) from comment #3)
> My recommendation would be to go with #2, if you all agree I am happy to
> update the plugin.

If you need a websec opinion: I agree :)

(Discussed the example URL with Tanvi out of band - the updated URL covers a test case that persists ;))
Plugin updated here:

https://github.com/bensternthal/Smartsheet-MediaWiki-Extension

If you can deploy to a dev or stage environment I would be happy to help test.
I will get an update from SmartSheet on when they will handle HTTPs embeds. They said they are working on it.
Just to clarify, smartsheet does support https for a type of embed just not for all embeds.

The above solution uses the https embed they currently support.

We should still push them to support https on all types of embeds.
I'm on the web app sec team, tracking the mixed content bug deps. 

My question - is there an eta for when the changes will be deployed to the public web?
(In reply to Adam Muntner :adamm from comment #9)
> I'm on the web app sec team, tracking the mixed content bug deps. 
> 
> My question - is there an eta for when the changes will be deployed to the
> public web?

We have a solution that will switch them to HTTPS, but it is not idea from a user experience level. I am waiting for a email back from SmartSheet on the status of enabling https for the publish.smartsheet.com sub-domain.
Chris please also note the cert issue with publish.smartsheet.com mentioned in the first comment.
(In reply to Ben (:bensternthal) from comment #11)
> Chris please also note the cert issue with publish.smartsheet.com mentioned
> in the first comment.

Yes. I'm aware. SmartSheet's VP is going to contact us tomorrow on a workaround as enabing SSL on the publish.smartsheet.com domain is not as straightforward as you would assume.
Chris, what did you hear from them?
(In reply to Adam Muntner :adamm from comment #13)
> Chris, what did you hear from them?

That Ben's solution of using the full embed is the only solution for now. They are looking into ways of using https on the s3 network with how they are handling content refreshes. We just need to get Ben's code reviewed and updated on wiki.mo.
Thanks Chris. Any word on when this will fit on the calendar?
Jake can we get my super-terrific fix for this on wiki-dev.allizom.org for testing?

Code is in same place:
https://github.com/bensternthal/Smartsheet-MediaWiki-Extension
Flags: needinfo?(nmaul)
Just following up - the new FF beta has mixed content blocking enabled, this is pretty much a dogfood issue.
(In reply to Adam Muntner :adamm from comment #17)
> Just following up - the new FF beta has mixed content blocking enabled, this
> is pretty much a dogfood issue.

Adam: Ben's fix in comment 16 is done. We are blocked on IT to get this updated on the blog.

Ben: do you want to ping IT next week?
I have a note to check in with IT at the end of the month. This is not a high priority and as long as we fix it before August we should be fine.

Given the competition for Jake's attention this is not a bug I want to overly bother his team with.
Jake: Can you let me know when you think we can roll this out? Not a rush, but a date will help me plan.
Component: Server Operations: Web Operations → WebOps: IT-Managed Tools
Product: mozilla.org → Infrastructure & Operations
Assignee: server-ops-webops → cliang
I updated just the Smartsheet extension and pushed it out to the servers.  Please let me know if there needs to be a broader update of wiki-dev.allizom.org.

[cliang@genericadm.private.phx1 Smartsheet-MediaWiki-Extension]$ sudo git pull
remote: Counting objects: 7, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 4 (delta 2), reused 4 (delta 2)
Unpacking objects: 100% (4/4), done.
From https://github.com/bensternthal/Smartsheet-MediaWiki-Extension
   66a6f35..2268fe4  master     -> origin/master
Updating 66a6f35..2268fe4
Fast-forward
 README.md            | 7 +++++++
 SmartsheetIframe.php | 4 +++-
 2 files changed, 10 insertions(+), 1 deletion(-)

[cliang@genericadm.private.phx1 wiki-dev.allizom.org]$ sudo /data/genericrhel6-dev/deploy wiki-dev.allizom.org
[2013-07-18 07:22:53] Running rsync_project
[2013-07-18 07:22:53] [localhost] running: /usr/bin/rsync -aq --include '.gitkeep' --exclude '.git*' --exclude '.hg*' --exclude '.svn*' --exclude 'CVS' --exclude '.bzr*' --delete /data/genericrhel6-dev/src/wiki-dev.allizom.org/ /data/genericrhel6-dev/www/wiki-dev.allizom.org/
[2013-07-18 07:22:55] [localhost] finished: /usr/bin/rsync -aq --include '.gitkeep' --exclude '.git*' --exclude '.hg*' --exclude '.svn*' --exclude 'CVS' --exclude '.bzr*' --delete /data/genericrhel6-dev/src/wiki-dev.allizom.org/ /data/genericrhel6-dev/www/wiki-dev.allizom.org/ (2.113s)
[2013-07-18 07:22:55] Finished rsync_project (2.113s)
[2013-07-18 07:22:55] Running commit_www
[2013-07-18 07:22:55] [localhost] running: cd /data/genericrhel6-dev/www && /usr/bin/git add .; /usr/bin/git commit -a -m 'deploy ['wiki-dev.allizom.org']'
[2013-07-18 07:23:10] [localhost] finished: cd /data/genericrhel6-dev/www && /usr/bin/git add .; /usr/bin/git commit -a -m 'deploy ['wiki-dev.allizom.org']' (14.753s)
[localhost] out: [master ca31882] deploy [wiki-dev.allizom.org]
[localhost] out: 6 files changed, 13 insertions(+), 4 deletions(-)
[localhost] out: create mode 100644 wiki-dev.allizom.org/wiki-backup-20130718.tar.gz
[2013-07-18 07:23:10] Finished commit_www (14.753s)
[2013-07-18 07:23:10] Running push_www
[2013-07-18 07:23:10] [generic1.dev.webapp.phx1.mozilla.com] running: /data/bin/update-www.sh wiki-dev.allizom.org
[2013-07-18 07:23:43] [generic1.dev.webapp.phx1.mozilla.com] finished: /data/bin/update-www.sh wiki-dev.allizom.org (32.946s)
[generic1.dev.webapp.phx1.mozilla.com] out: Not removing ship-it-dev.allizom.org/release-kickoff/logs/
[generic1.dev.webapp.phx1.mozilla.com] out: Not removing whistlepig-dev.allizom.org/WhistlePig/static/CACHE/
[2013-07-18 07:23:43] Finished push_www (32.947s)
Assignee: cliang → server-ops-webops
Flags: needinfo?(nmaul)
Tested this code. Looks fine to me. No https related errors and content is not blocked.

My test page:

https://wiki-dev.allizom.org/Main_Page/test-smartsheet
What do existing wiki's do to fix this?  Like https://wiki.mozilla.org/IT/Projects/Project-Dashboard-2013Q3
(In reply to Tanvi Vyas [:tanvi] from comment #25)
> What do existing wiki's do to fix this?  Like
> https://wiki.mozilla.org/IT/Projects/Project-Dashboard-2013Q3

We shouldn't have to do anything. When the plugin is pushed to prod, the code that generates the iframe will change from http to https. The protocol is abstracted from the presentation layer. 

I didn't touch this page and the iframe is https now:

https://wiki-dev.allizom.org/Webdev/Web_Production/Project-Dashboard

Ben, are we good to go to prod?
(In reply to Chris More [:cmore] from comment #26)
> (In reply to Tanvi Vyas [:tanvi] from comment #25)
> > What do existing wiki's do to fix this?  Like
> > https://wiki.mozilla.org/IT/Projects/Project-Dashboard-2013Q3
> 
> We shouldn't have to do anything. When the plugin is pushed to prod, the
> code that generates the iframe will change from http to https. The protocol
> is abstracted from the presentation layer. 
> 
> I didn't touch this page and the iframe is https now:
> 
> https://wiki-dev.allizom.org/Webdev/Web_Production/Project-Dashboard
> 
> Ben, are we good to go to prod?

Unlike the page on wiki.mozilla.org, I see this page correctly (spreadsheet and all) in this trunk nightly:

Mozilla/5.0 (X11; Linux i686 on x86_64; rv:25.0) Gecko/20100101 Firefox/25.0 SeaMonkey/2.22a1 ID:20130718003001 c-c:3efb0311a21c m-c:f26e4c26ce4a
(In reply to Chris More [:cmore] from comment #26)
> We shouldn't have to do anything. When the plugin is pushed to prod, the
> code that generates the iframe will change from http to https. The protocol
> is abstracted from the presentation layer. 
> 

Ah okay, great!
Yes see https://bugzilla.mozilla.org/show_bug.cgi?id=875231#c24 confirmed we are good to go to production.
Attached file smartsheet_push.log — 
I performed the same Smartsheet extension update on stage and prod, then pushed it out to the servers.  Please let me know if anything has gone awry.
Looks good, thanks again for all your help.

If we find a bug or other issue we can re-open.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Still an issue:

https://wiki.mozilla.org/IT/Projects/Project-Dashboard-2013Q3
Status: RESOLVED → REOPENED
Keywords: verifyme
Resolution: FIXED → ---
Looks ok with aurora, it renders and no shield. Maybe cache?
(In reply to Ben (:bensternthal) from comment #33)
> Created attachment 778182 [details]
> Screen Shot 2013-07-18 at 5.33.57 PM.png
> 
> Looks ok with aurora, it renders and no shield. Maybe cache?

Mozilla/5.0 (X11; Linux i686 on x86_64; rv:25.0) Gecko/20100101 Firefox/25.0 SeaMonkey/2.22a1 ID:20130718003001 c-c:3efb0311a21c m-c:f26e4c26ce4a

Now it displays correctly for me, while shortly after comment #30 it didn't. Maybe a cache problem, as you say.

Tanvi, if the display is still wrong from you, try Ctrl+Shift+R (i.e., refresh ignoring cache).
Right now, the shield is gone and no Mixed Active Content is detected.

But in actuality, there is Mixed Active Content on the page.  Firefox isn't catching it because of a bug with Content Policy and redirects (that will be fixed as part of https://bugzilla.mozilla.org/show_bug.cgi?id=878890).

The wiki page https://wiki.mozilla.org/IT/Projects/Project-Dashboard-2013Q3 includes what appears to be an https iframe:

<iframe name="smartsheet" frameborder="0" src="https://www.smartsheet.com/b/publish?embed=true&amp;EQBCT=89f227c3b8bd433cad0f9ed765675306" width="100%" height="700"></iframe>

Since the Mixed Content Blocker thinks the frame is over SSL, it allows the content.  The request for https://www.smartsheet.com/b/publish?embed=true&EQBCT=89f227c3b8bd433cad0f9ed765675306 then returns a 301 redirect to an https page.  The redirected page then returns a 302 redirect to an HTTP pages (http://publish.smartsheet.com/89f227c3b8bd433cad0f9ed765675306).  So the actual frame source is HTTP (not HTTPS).  And Firefox doesn't catch this (yet) because our Mixed Content Detection doesn't account for redirects.

My guess is that if you test this with IE, you will see there Mixed Content Blocker show up.

Once we fix Bug 878890, the Shield will come back in Firefox too.
Here with trunk SeaMonkey, yesterday I didn't see the iframe at all.

Now I do see it, but with a pink notification bar, “You have requested an encrypted page that contains some unencrypted information.” (etc.) and, on the statusbar, a pink button with a padlock which is closed but barred by a red diagonal.
Well that is quite a bummer. 

OK from our end I do not think we have any options other than to pressure smartsheet to make sure HTTPS works for embedding. This is something they have to fix.

Chris, can you find out if there is any sort of ETA from smartsheet. If they can not provide a date or it's very far into the future we should discuss alternatives for embeddable sheets.
Flags: needinfo?(chrismore.bugzilla)
Ok, I think I know what is going on here. The SSL publishing of SmartSheet only works with the full read-only publish URL. The embed here https://wiki.mozilla.org/IT/Projects/Project-Dashboard-2013Q3, which initially uses SSL redirects because the html read-only uses content up on S3 that isn't SSL. For this to work, end users of the embedded sheets will have to use the full embed.

If this is true, the following URL should load and not throw mix content errors:

https://wiki.mozilla.org/Webdev/Web_Production/Project-Dashboard

(please shift refresh that URL)

:tanvi: can you confirm?

Also, I've asked SmartSheet their timeline for full SSL support regardless of html or full embeds.
Flags: needinfo?(chrismore.bugzilla)
Tested The Following In IE:

https://wiki.mozilla.org/IT/Projects/Project-Dashboard-2013Q3 
https://wiki.mozilla.org/Webdev/Web_Production/Project-Dashboard

Neither has an alert about mixed content so I am unable currently to reproduce an error.

I would be comfortable closing this for now. If it turns out a few smartsheets are not loading we can debug them individually to see if they are embedding the version Cmore references above.
Cool, I'll close it then :)
Status: REOPENED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
When visiting https://wiki.mozilla.org/IT/Projects/Project-Dashboard-2013Q3 in Chrome, the console says the following:

The page at about:blank displayed insecure content from http://publish.smartsheet.com/89f227c3b8bd433cad0f9ed765675306.

Chrome identifies the content as Mixed Content because they don't have the redirect bug that Firefox has.  The content isn't blocked yet (but Chrome is planning on blocking Mixed Content iframes soon).

I'm not sure why Internet Explorer is not catching the issue.  I haven't tested how they handle mixed content redirects, but will at some point.

This isn't an issue today (because Firefox has a bug) but will be when Bug 878890 is fixed.  So maybe I can make that bug block this one?  If we close it, will we remember to go back and fix the issue once Firefox does handle redirects correctly?
(In reply to Chris More [:cmore] from comment #38)
> Ok, I think I know what is going on here. The SSL publishing of SmartSheet
> only works with the full read-only publish URL. The embed here
> https://wiki.mozilla.org/IT/Projects/Project-Dashboard-2013Q3, which
> initially uses SSL redirects because the html read-only uses content up on
> S3 that isn't SSL. For this to work, end users of the embedded sheets will
> have to use the full embed.

Hi Chris.  Are you saying that if our wiki embeds the full embedded sheet, we will have a full SSL experieince?  But if our wiki embeds the read only version, we end up getting the content over HTTP.

Can we (or should we) change the currently embedded read-only smartsheets with full embeds?  There are some downsides to doing this:
1) you need to allow third party cookies to see full-embed smartsheets
2) they take longer to load.
I'm not sure if this is even possible on our end.  How do we know the difference between an embedded read-only page and non-read-only page?


> If this is true, the following URL should load and not throw mix content
> errors:
> 
> https://wiki.mozilla.org/Webdev/Web_Production/Project-Dashboard
> 
> (please shift refresh that URL)
> 
> :tanvi: can you confirm?

I don't have any Mixed Content issues on that page.  The following iframe is embedded:
<iframe name="smartsheet" frameborder="0" src="https://www.smartsheet.com/b/publish?embed=true&amp;EQBCT=355f3fbc546c441e8bb02955be648bc6" width="100%" height="700"></iframe>

A request for the iframe source results in a 301 Moved Permanently to:
https://app.smartsheet.com/b/publish?embed=true&EAQBCT=355f3fbc546c441e8bb02955be648bc6

This is HTTPS and returns 200 okay, so we are good.

> 
> Also, I've asked SmartSheet their timeline for full SSL support regardless
> of html or full embeds.
Please let us know what they say.  Thanks!
Depends on: 878890
it seems this issue remains so I will reopen this bug... for now. I say for now as I do not see any item that is actually actionable for webops. I will need someone to either specify what is actionable for webops or to kindly assign this to a component that has actionable items. Elsewhise the bug will be closed again as there is no need for a bug if there is no possible action.

Regards
Status: RESOLVED → UNCONFIRMED
Ever confirmed: false
Resolution: FIXED → ---
For this bug to be fixed, one of 2 things can happen:

* We change all the wiki embeds to full embeds instead of read only embeds.  I don't know if this is possible.

* SoundCloud makes changes to add SSL support for readonly embeds.  Once the support is in place, we update the wiki read-only embed links if necessary (i.e. if the links to support ssl are different than the currently used links).

I can't comment on who has the ability to do either of these things or who this bug should be assigned to.
Tanvi:

I think this bug covers point 1 only. I dont want to track smartsheet fixing something on their end here. We can do that but I think it should be under a different tracker.

This tracker (to me) are things we can fix ourselves.

So back to the solution. 

I suggest we fix these on a case by case basis as we find them. 

** There are probably only a handful of smartsheet's embedded in the wiki. 
** Given everything else, this is low priority

I suggest closing this one out. If we find any broken smartsheets we do the following:

- open a bug
- find whomever owns the page via the history
- contact them to tell them to update the smartsheet embed 
- if they dont want to do that, they can just link to a public url and avoid this all together
(In reply to Ben (:bensternthal) from comment #46)
> Tanvi:
> 
> I think this bug covers point 1 only. I dont want to track smartsheet fixing
> something on their end here. We can do that but I think it should be under a
> different tracker.
> 
Okay sounds good.  Can you file a separate bug for that that blocks bug 844556.

> This tracker (to me) are things we can fix ourselves.
> 
> So back to the solution. 
> 
> I suggest we fix these on a case by case basis as we find them. 

Okay, also sounds good.  Can we fix https://wiki.mozilla.org/IT/Projects/Project-Dashboard-2013Q3 to make it a full embed, and then close this?
> Okay, also sounds good.  Can we fix
> https://wiki.mozilla.org/IT/Projects/Project-Dashboard-2013Q3 to make it a
> full embed, and then close this?

I've reached out to IT and they are going to switch it to a full embed. Will post here when they have it switched.
(In reply to Chris More [:cmore] from comment #48)
> > Okay, also sounds good.  Can we fix
> > https://wiki.mozilla.org/IT/Projects/Project-Dashboard-2013Q3 to make it a
> > full embed, and then close this?
> 
> I've reached out to IT and they are going to switch it to a full embed. Will
> post here when they have it switched.

It looks like this wiki pages uses a full embed now.  Closing.

To track smartsheet providing SSL for their read only embeds, see bug https://bugzilla.mozilla.org/show_bug.cgi?id=897754.
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago → 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: