Updates trypurescript to work with Halogen Affjax example

[mikesol]

Currently, the affjax example in Halogen does not work and returns the following response:

Blocked form submission to '' because the form's frame is sandboxed and the 'allow-forms' permission is not set.

I believe this fixes the issue, although I haven't tested it yet. Thanks!

[milesfrain]

Here's the example for reference:
https://try.purescript.org/?gist=c92a6483c0204a9fc944e3b5b2cf8997

From this section:
https://purescript-halogen.github.io/purescript-halogen/guide/03-Performing-Effects.html#an-aff-example-http-requests

[hdgarrood]

Thanks for the PR. I’d like to do a bit of research about the security implications of allowing forms here before accepting. (I assume that allow-forms is disabled by default for a reason).

[thomashoneyman]

@hdgarrood as far as I understand it, the risk of allowing forms via an iframe is that the form submission can POST some data off to a server when you may not have wanted that. Yet due to allow-scripts we already let you communicate with external servers.

For example, in the linked Halogen example if you use the click event instead of the submission event then the request goes through perfectly fine. So I'm not sure what we gain by blocking form submission within this iframe.

[natefaubion]

Does the form submission let you navigate away from the host page within the frame?

[thomashoneyman]

I believe that to do that you would have the form trigger a JS handler which changes the iframe location. But I also think that's already possible to do via allow-scripts. For example, within the console for the iframe I can do this:

Resources are blocked by the same-origin policy, but navigation seems possible.

[natefaubion]

It's not clear to me your dev console is executing within the context (security policy) of the inner iframe. I don't think testing it in the dev console is a robust way of verifying the security of it.

[thomashoneyman]

I agree that the dev console isn't the proper way to check this. That said, the console is executing within the JS context of the iframe:

Though perhaps that doesn't necessarily mean it's subject to the iframe's security policy. It seems that it is, but I'm open to suggestions for better ways to check this.

[natefaubion]

I would verify it with DOM APIs in PureScript code if available. If the APIs are unavailable, you can hack around it with unsafeCoerce.

[thomashoneyman]

The APIs are unavailable (from a quick glance through Pursuit), so I can hack around it later today.

[natefaubion]

I was able to use

module Main where

import Prelude

import Effect (Effect)
import Web.HTML (window)
import Web.HTML.Location (setHref)
import TryPureScript 
import Debug.Trace
import Unsafe.Coerce (unsafeCoerce)

main :: Effect Unit
main = do
  win <- window
  let loc = (unsafeCoerce win).frames.location
  setHref "https://google.com" loc
  pure unit

and it was blocked

[natefaubion]

So as long as a form submission does the same thing I'm ok with allowing it.

[natefaubion]

Oh whoops! that's due to a header on google.com specifically. You are correct, unfortunately allow-scripts does let you change the location within the iframe. I'm inclined to agree with you then.

[thomashoneyman]

Fortunately it doesn't navigate the top-level window and the iframe is still sandboxed.

[thomashoneyman]

Given the discussion we've had so far, I think that adding this functionality doesn't increase our security risk and unblocks a nice use case for Try PureScript.