Bug 130398 – [WK2][GTK] Expose the enable-web-security property in WebKit2GTK API

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebKitGTK

[Mario Sanchez Prada]

It would be very convenient to be able to disable the same-origin policy in WebKit2GTK+ based browsers for the purpose of testing certain websites and/or running specific test suites (such as the one for CSS2.1 [1), meaning that we would need to expose WebCore::Settings's webSecurityEnabled property for apps to be able to disable it (although it should be activated by default).

See more details in the mail sent to webkit-gtk mailing list:
https://lists.webkit.org/pipermail/webkit-gtk/2014-March/001818.html

[1] http://test.csswg.org/suites/css2.1/

[Mario Sanchez Prada]

Created attachment 227057 [details]
Patch proposal

Here comes a patch. I added documentation and unit testing to it, so I guess nothing is missing, but you know... there's always something :)

Please review, thanks!

[WebKit Commit Bot]

Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See http://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API

[Mario Sanchez Prada]

Carlos, Gustavo, Martin & others... any comment on this?

There was some positive feedback in the ML about it, btw:
https://lists.webkit.org/pipermail/webkit-gtk/2014-March/001819.html

[Mario Sanchez Prada]

Ping?

[Grzegorz Czajkowski]

Comment on attachment 227057 [details]
Patch proposal

This option can be very useful for testing. FYI, we exposed it for EFL's MiniBrowser as well (bug 121095).

[Mario Sanchez Prada]

(In reply to comment #5)
> (From update of attachment 227057 [details])
> This option can be very useful for testing. FYI, we exposed it for EFL's MiniBrowser as well (bug 121095).

I just pinged Carlos today on IRC about this. Let's see if we can get it soon

[Carlos Garcia Campos]

If it's useful for testing, why do we want it in the public API?

[Mario Sanchez Prada]

(In reply to comment #7)
> If it's useful for testing, why do we want it in the public API?

As per IRC log:

<KaL> msanchez: if it's useful for testing why do we want it in the public API?
<msanchez> well, it might be useful for other use cases too
<msanchez> anyway, having it exposed in the web API will also allow people to use minibrowser (or any other webkit2gtk based browser allowing to set that setting) to test web apps and test harnesses
<msanchez> I understand for epiphany it's probably not useful, but it could be useful for other browsers that might want (for whatever the reason) to allow users to disable those checks
<msanchez> what alternative do you propose?

[Mario Sanchez Prada]

More from IRC:

  <KaL> msanchez: I don't have any proposal because I don't even know what those checks are
  <msanchez> KaL: I was talking about the "same-origin" policy
  <KaL> ah, cross-origin problems
  <msanchez> where the browser won't allow executing scripts coming from a different origin/domain/whatever than the one the document belongs to
  <msanchez> or something like that (not an expert either)
  <msanchez> yes
  <KaL> yes, I see
  <msanchez> it seems to be a major problem for some test suites
  <msanchez> and I can imagine there might be very especific use cases where people might want to disable those too 
  <KaL> sounds like everybody will turn that off the first time they face a cross-origin issue
  <msanchez> well, IMHO depending on the audience of a given browser, that browser might want to expose that setting or not
  <KaL> but anyway, if kov and mrobinson are fine, I'm not opposed


Martin, Gustavo... what's your take?

[Mario Sanchez Prada]

(In reply to comment #9)
> More from IRC:
> 
>   <KaL> msanchez: I don't have any proposal because I don't even know what those checks are
>   <msanchez> KaL: I was talking about the "same-origin" policy
>   <KaL> ah, cross-origin problems
>   <msanchez> where the browser won't allow executing scripts coming from a different origin/domain/whatever than the one the document belongs to
>   <msanchez> or something like that (not an expert either)
>   <msanchez> yes
>   <KaL> yes, I see
>   <msanchez> it seems to be a major problem for some test suites
>   <msanchez> and I can imagine there might be very especific use cases where people might want to disable those too 
>   <KaL> sounds like everybody will turn that off the first time they face a cross-origin issue
>   <msanchez> well, IMHO depending on the audience of a given browser, that browser might want to expose that setting or not
>   <KaL> but anyway, if kov and mrobinson are fine, I'm not opposed
> 
> 
> Martin, Gustavo... what's your take?

Ping again?

[Martin Robinson]

I'm not a huge fan of this API, but I'm not going to oppose it. It's pretty easy to boot up a Python web server for testing locally.

[Mario Sanchez Prada]

Comment on attachment 227057 [details]
Patch proposal

I'm removing the r? flag based on the feedback got so far, I can always apply this locally when needed. Anyone more interested on this please feel free to push it yourself.

[Martin Robinson]

(In reply to comment #12)
> (From update of attachment 227057 [details])
> I'm removing the r? flag based on the feedback got so far, I can always apply this locally when needed. Anyone more interested on this please feel free to push it yourself.

Sorry, I didn't want to cause you to give up on the patch. If other browsers still ship this flag and we're pretty sure the option won't be removed, we should probably do it too.

[Mario Sanchez Prada]

(In reply to comment #13)
> (In reply to comment #12)
> > (From update of attachment 227057 [details] [details])
> > I'm removing the r? flag based on the feedback got so far, I can always apply this locally when needed. Anyone more interested on this please feel free to push it yourself.
> 
> Sorry, I didn't want to cause you to give up on the patch. If other browsers still ship this flag and we're pretty sure the option won't be removed, we should probably do it too.

No problem. Thing is that I don't have a strong enough reason myself to push it other than what I found while trying to run those test suites, which was a problem shared by another person too in the mailing list

Because of that, I thought it might be interesting to have this API there, but given the few interest that this patch seemed to cause, I came to the conclusion that perhaps is not that relevant anyway so there was no good reason for me to push it anymore.

Besides, the patch is not rocket science either, so it could be applied at any further point anyway, if needed :)

[Mario Sanchez Prada]

Resolving as WONTFIX. If anyone detects this functionality is needed in the future, creating the patch again or simply reusing this one here would be fairly straightforward

[Nicolas Dufresne]

Let's say we'd like to write an local application written in HTML that runs within WebKit, what would be the solution if not this API to let the local application load resources from the web ?

[Mario Sanchez Prada]

(In reply to comment #16)
> Let's say we'd like to write an local application written in HTML that runs
> within WebKit, what would be the solution if not this API to let the local
> application load resources from the web ?

After more than one year with this thing buried i nthe bugzilla, I recently stumbled into a situation quite similar to the one described by Nicolas, where the only way I could move forward was by disabling web-security.

To be clear, this happens in a context where I'm sure disabling this option does not pose any problem (i.e. not a full fledged browser), and where we control all the local content being loaded by the webview, meaning that there's no way anyone could inject a XSS attack or anything, pretty much like the case for testing the CSS test suite mentioned initially along with this bug report.

So, I'd like to get this discussion back to life again, see if we can agree on adding this property to the public API, so that embedders of WebKitGTK can use it if needed, without needing downstream patches.

[Mario Sanchez Prada]

Hmm... I think I was too fast. I just found bug 144748 and realized that, perhaps, the new API recently added to fix that is all we might need after all.

I'll give this a try when I have some time and will resolve this back to WONTFIX if that's the case, but feel free to post your comments anyway, if any.

[Nicolas Dufresne]

I think to the having a way to force allowing file:// would work for my case too (have a local web app acessing the web without having to implement custom URI).

[Mario Sanchez Prada]

(In reply to comment #18)
> Hmm... I think I was too fast. I just found bug 144748 and realized that,
> perhaps, the new API recently added to fix that is all we might need after
> all.
> 
> I'll give this a try when I have some time and will resolve this back to
> WONTFIX if that's the case, but feel free to post your comments anyway, if
> any.

This worked good enough for me too so I'm re-resolving this as WONTFIX. Sorry for the noise. 

(In reply to comment #19)
> I think to the having a way to force allowing file:// would work for my case
> too (have a local web app acessing the web without having to implement
> custom URI).

It sounds like you're trying to do something similar to what we are doing, so I'm confident it will work for you too.