Add a (temporary) global pref to ignore X-Frame-Options

RESOLVED FIXED in mozilla12

Status

()

Core
Document Navigation
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: cjones, Assigned: Justin Lebar (not reading bugmail))

Tracking

unspecified
mozilla12
x86
Linux
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

For testing the browser app in b2g, we'd like to temporarily disable X-Frame-Options checking.  This might be generally useful (maybe), so if we do this, I'd be happy to make it a pref and land on m-c.  We won't need this workaround for too long.

If anyone strongly objects, or no one else would find it useful, we can close out this bug.
I was going to set this as blocking browser-as-webapp (https://bugzilla.mozilla.org/show_bug.cgi?id=693515) but what's described here is just a workaround.

If this is a workaround, what is the long term solution? Should all <iframe browser> elements ignore X-Frame-Options and continue to render the page?
(Assignee)

Comment 2

6 years ago
(In reply to Ben Francis from comment #1)
> If this is a workaround, what is the long term solution? Should all <iframe
> browser> elements ignore X-Frame-Options and continue to render the page?

Yes, I think so.

Is this really getting in your way at the moment?
No it's not getting in my way at all because I just test the browser on pages without X-Frame-Options, but it will certainly get in users' way. 

Google, Facebook, Twitter, YouTube, GMail, Google Calendar, Github... most popular web apps disallow rendering inside iFrames in order to prevent phishing. That makes it a blocker as far as a useful browser is concerned.
(Assignee)

Comment 4

6 years ago
The question is: Should we hack around it, or fix it properly?  We can probably fix it properly, unless it's getting in your way right now and you need a fix.
(Assignee)

Comment 5

6 years ago
It sounds like from IRC that cjones thinks this will be In The Way within a week.
<cjones> hi bz, are you ok with a quick hack to disable x-frame-options checking, behind a pref?
<cjones> this is to unblock the browser app for b2g, for a quarterly goal
<cjones> the downside is ugly, sorry
<cjones> upside is we can start testing the browser in real phones sooner
* jfkthame (jfkthame@7CAC30AF.5BC345F5.9542EC20.IP) has joined #developers
* Mano has quit (Ping timeout)
<pr0pagandhi> any plans for an iOS version?
* Wes (chatzilla@A1FEE3E8.E3DA2587.9A5171B3.IP) has joined #developers
<smaug> ted: ^
* smontagu (chatzilla@moz-13AE8AF9.red.bezeqint.net) has joined #developers
* mcote|chiro is now known as mcote
<khuey> I think that project died with native UI for android
<bz> cjones: worksforme
* victorporof (victorporo@3E36101D.6BD22D89.79933D60.IP) has joined #developers
<khuey> hmm
* victorporof has quit (Connection reset by peer)
<bz> cjones: can you make it check system prefs only?
<bz> cjones: so users can't set it by accident?

Justin might be able to get to this today.  If not, please un-assign.

When we have bug 704037 or a followup, we will remove this hack.
Assignee: nobody → justin.lebar+bug
Depends on: 704037
Duplicate of this bug: 712974
Summary: Add a global pref to ignore X-Frame-Options → Add a (temporary) global pref to ignore X-Frame-Options
(Assignee)

Comment 8

6 years ago
Created attachment 583853 [details] [diff] [review]
Patch v1
(Assignee)

Updated

6 years ago
Attachment #583853 - Flags: review?(bzbarsky)
Comment on attachment 583853 [details] [diff] [review]
Patch v1

Won't this possibly still pick up user.js values for this pref?
(Assignee)

Comment 10

6 years ago
I thought lockPref() was supposed to prevent that?
I don't know.  Does it take effect dynamically?
(Assignee)

Comment 12

6 years ago
I added 

  user_pref("b2g.ignoreXFrameOptions", true);

to my user.js.  Now when I view the pref in about:memory, it has status "locked".  Checking what the value is returned by the pref branch...
(Assignee)

Comment 13

6 years ago
And with that pref set in user.js and the lockPref() call in place, the pref reads as false.  When I take out the lock, it reads as true.

Now, it appears that Google has other framebusting code in place, so the page still doesn't load properly with this pref set...
(Assignee)

Comment 14

6 years ago
Created attachment 583883 [details] [diff] [review]
Patch v2

Move x-frame-options check into CheckFrameOptions, which has the advantage of working.

(It worked sometimes as in patch v1, but it works consistently this way.)
(Assignee)

Updated

6 years ago
Attachment #583853 - Attachment is obsolete: true
Attachment #583853 - Flags: review?(bzbarsky)
(Assignee)

Comment 15

6 years ago
Comment on attachment 583883 [details] [diff] [review]
Patch v2

I checked that this works on desktop (if I comment out lockPref()) and that when the lock is there, my setting in user_pref is ignored.
Attachment #583883 - Flags: review?(bzbarsky)
Comment on attachment 583883 [details] [diff] [review]
Patch v2

r=me
Attachment #583883 - Flags: review?(bzbarsky) → review+
https://hg.mozilla.org/mozilla-central/rev/00f4c8c5bcc7
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla12
Cool, thanks :)
(Assignee)

Updated

5 years ago
Blocks: 770239
You need to log in before you can comment on or make changes to this bug.