965003 - New ADP site won't show PDF (paystubs, W2s, etc) in <embed>, due to apparent CSP violation with PDF.js: "Content Security Policy: The page's settings blocked the loading of a resource at data:application/x-moz-playpreview-pdfjs;,"

Status: RESOLVED INCOMPLETE

(Core :: DOM: Security, defect)

Description

[Daniel Holbert [:dholbert]]

[I'm not sure whether this bug belongs in Security, or PDF.js, or in Tech Evang (as an ADP bug). Starting out in Security, and we can go from there]

STR:
 0. Be a US-based Mozilla employee or have an account with ADP.

 1. Log in to the new ADP page (which payroll@ recently notified us about in an email to US employees):
     http://www.portal.adp.com/
    (Your existing ADP iPay credentials will work.)

 2. Under the "Pay & Taxes" menu, pick "Pay Statements"

 3. Click one of the Pay Date entries, to try to view a paystub.

EXPECTED RESULTS: PDF should be rendered (by PDF.js) in the large <embed> area on the page

ACTUAL RESULTS: The PDF is not rendered, and there's no way (as far as I can tell) to download it. Moreover, this appears in the error console:
{
Content Security Policy: The page's settings blocked the loading of a resource at data:application/x-moz-playpreview-pdfjs;, ("default-src https://portal.adp.com:443 https://*.adp.com:443 https://*.google.com:443").
}

Comment 1

[Daniel Holbert [:dholbert]]

I was hoping I could work around this via [ Firefox Preferences | Applications | scroll down to PDF and pick something other than "Preview in Nightly", but that doesn't work -- then the page renders with a "Plugin Needed to display this content" UI.

I'm guessing ADP must've tested this with Adobe PDF reader plugin, which (maybe?) loads embedded PDFs in a different way such that it doesn't violate the CSP. (And apparently they don't have any fallback if you don't have any PDF reader plugin, which is quite annoying, but is a different issue from the CSP problem here.)

Comment 2

[Daniel Holbert [:dholbert]]

HACKAROUND:
If I use "inspect element" and manually edit the live page's DOM to replace
   <embed src="..."
with
   <object data="..."
then it works correctly.

(This is definitely not easy enough to be a useful hackaround in-practice; I'm more posting it for the purposes of figuring out what's going on here.)

Comment 3

[Daniel Holbert [:dholbert]]

This affects both Nightly and Release, so it's not a Firefox regression or anything.
* Nightly version tested:
   Mozilla/5.0 (X11; Linux x86_64; rv:29.0) Gecko/20100101 Firefox/29.0
   (Help|About shows  29.0a1 (2014-01-27))

* Release version tested:
   Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:26.0) Gecko/20100101 Firefox/26.0

I verified that the hackaround from Comment 2  works in both of those builds, too.

Comment 4

[Daniel Holbert [:dholbert]]

(adding <embed> to summary, per Comment 2)

If appropriate (not sure), it might be worth spinning off a separate Tech Evang bug to ask ADP to switch to using <object> here. (I don't claim to know why it matters, but it apparently does currently. And still worth keeping this bug open on fixing <embed>.)

ALSO: Chrome doesn't seem to be affected by this bug; I tried the STR there, and I also tried performing the Comment 2 live-edit tweak in Chrome, and it renders the embedded PDF just fine in both situations. (This is Chrome version 32.0.1685.0 dev)

Comment 5

[Yury Delendik (:yury)]

In a nutshell, current plugin architecture does not provide enough flexibility to write js plugins that will replace NPAPI stuff especially those that are initialized via EMBED tag. There is bug 558184 in the works to fix that and replace PlayPreview hack that was introduce to create "preview" iframe that runs HTML content instead of Click-to-play display.

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to Yury Delendik (:yury) from comment #5)
> In a nutshell, current plugin architecture does not provide enough
> flexibility to write js plugins that will replace NPAPI stuff especially
> those that are initialized via EMBED tag.

Can you elaborate? I don't understand how that impacts this bug.

(Note that <embed> and <object> can both successfully render PDF content with PDF.js, in a local testcase on my machine.)

Comment 7

[Yury Delendik (:yury)]

(In reply to Daniel Holbert [:dholbert] from comment #6)
> (In reply to Yury Delendik (:yury) from comment #5)
> > In a nutshell, current plugin architecture does not provide enough
> > flexibility to write js plugins that will replace NPAPI stuff especially
> > those that are initialized via EMBED tag.
> 
> Can you elaborate? I don't understand how that impacts this bug.
> 
> (Note that <embed> and <object> can both successfully render PDF content
> with PDF.js, in a local testcase on my machine.)

Sure. Handling of EMBED tag is a little bit different from OBJECT. To make if work for EMBED, we had to use PlayPreview stuff (see bug 776208 attachment 653108 [details]) to create an overlay that belongs to the document, has URL that is "data:application/x-moz-playpreview-pdfjs;,", which eventually executes PDF.js via stream converter for application/x-moz-playpreview-pdfjs content. So looks like CSP is rejecting this URL. For comparison with OBJECT, the PDF.js stream converter "caches" application/pdf content before creating NPAPI plugin object, so everything is fine there.

Comment 8

[Daniel Holbert [:dholbert]]

Thanks, Yury.

Two more notes here:
 * <iframe> seems to work just fine (like <object>), and in fact ADP's older ipay.adp.com site uses <iframe> for PDF-embedding.
 * I filed bug 965050 as a tech evang bug, per comment 4, since it seems that making this work in <embed> is non-trivial at the moment.

Comment 9

[Yury Delendik (:yury)]

The bug 1179262 shall fix/avoid the this issue. I was unable to verify it though -- portal.adp.com hangs after login atm.

Comment 10

[Christoph Kerschbaumer [:ckerschb]]

Daniel, going through old bugs at the moment. I can't reproduce the issue, so I suppose it's fixed. Do you wanna try yourself? If you also can't reproduce, we could close this bug!

Comment 11

[Daniel Holbert [:dholbert]]

I actually can't login at the URL from comment 0 anymore ( http://www.portal.adp.com/ which redirects to https://portal.adp.com/ ) -- it rejects the username/password that I use for ADP's older site (https://ipay.adp.com/).

So from my perspective this is INCOMPLETE (no way to test it anymore), though given comment 9 it sounds like it's likely FIXED.