Taylor Cressy commented on SPARK-23983:

[~jpallas] That is unfortunate. Do we have a support matrix for the Spark UI 
(i.e. which versions of which browsers we want to support)? 


Is the option to turn off X-Frame-Options a potential approach instead?

> Disable X-Frame-Options from Spark UI response headers if explicitly 
> configured
> -------------------------------------------------------------------------------
>                 Key: SPARK-23983
>                 URL: https://issues.apache.org/jira/browse/SPARK-23983
>             Project: Spark
>          Issue Type: Improvement
>          Components: Web UI
>    Affects Versions: 2.3.0
>            Reporter: Taylor Cressy
>            Priority: Minor
>              Labels: UI
> We should introduce a configuration for the spark UI to omit X-Frame-Options 
> from the response headers if explicitly set.
> The X-Frame-Options header was introduced in *org.apache.spark.ui.JettyUtils* 
> to prevent frame-related click-jacking vulnerabilities. This was addressed 
> in: SPARK-10589
> {code:java}
> val allowFramingFrom = conf.getOption("spark.ui.allowFramingFrom")
> val xFrameOptionsValue =
>    allowFramingFrom.map(uri => s"ALLOW-FROM $uri").getOrElse("SAMEORIGIN")
> ...
> // In doGet
> response.setHeader("X-Frame-Options", xFrameOptionsValue)
> {code}
> The problem with this, is that we only allow the same origin or a singular 
> host to present the UI with iframes. I propose we add a configuration that 
> turns this off.
> Use Case: Currently building a "portal UI" for all things related to a 
> cluster. Embedding the spark UI in the portal is necessary because the 
> cluster is in the cloud and can only be accessed via an SSH tunnel - as 
> intended. (The reverse proxy configuration {{*_spark.ui.reverseProxy_* could 
> be used to simplify connecting to all the workers}}, but this doesn't solve 
> handling multiple, unrelated, UIs through a single tunnel.
> Moreover, the host that our "portal UI" would reside on is not assigned a 
> hostname and has an ephemeral IP address, so the *ALLOW-FROM* directive isn't 
> useful in this case.
> Lastly, the current design does not allow for different hosts to be 
> configured, i.e. *_spark.ui.allowFramingFrom_* _*hostname1,hostname2*_ is not 
> a valid config.
> An alternative option would be to explore Content-Security-Policy: 
> [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy#frame-ancestors]

This message was sent by Atlassian JIRA

To unsubscribe, e-mail: issues-unsubscr...@spark.apache.org
For additional commands, e-mail: issues-h...@spark.apache.org

Reply via email to