epa-wg / embed-page Goto Github PK

EPA / embed-page notes on JS scope, window and application security of scope insulation.

• anonymous default scope makes complete insulation
• none is a global scope, no insulation. Useful for html include
• scope="xxx" named. Variables and API are shared between scope with same name

How to hide the page scope(global) JS objects and substitute those with own implementation?

eval() with closure-defined global ovverrides appeared to be a way to make embed-page content insulation from host page. Here are the notes on implementation evolution.

There are multiple browsers with own capabilities on JS engine and available APIs application developers have to support. Build toolchains like webpack, various framework cli providing support for converting the source code to platform-specific compiled bundles. But in order to make cross-browser support efficient it is not enough to pick the lowest/oldest standard. On newer platforms with JS modules and web components the code would be a level of magnitude smaller and efficient if compiled accordingly. Which makes the platform-specific build switch so attractive.

The switch could be done by server side( web server filters ), CDN proxy rules, and finally by browser by JS. While embed-page supports dynamic switch of own content by pointing SRC attribute to appropriate build, EPA-WG should expose multiple ways of supporting this aspect of microapplication delivery via API, Docs, and reference implementation for platform-specific build switch of embed-page content.

polymer-cli, and other build toolchains allow to tune up the UI build for modern and legasy browsers. Here is a sample of bundle switch in JSP between build targetting es5 and es6 capable browsers.

The samples of build target switch to be extended to

• apache config
• cloudflare proxy
• embed-page API use

<embed-page> overall nuances.

Which leads as to CSS overlap as to mediaqueries mess-up.
https://jsfiddle.net/juL054e3/

For microapplication concept it is crucial to have an embedded script serving and accessing the content directly around the script without the need to identify the surrounding DOM. I.e. ability to traverse DOM starting from current script. The way around like dom identified with ID unfortunately is not universal as it could be multiple microapplications ( including same type ) presented on same host page. The dom insulation is not always applicable as scope=none disables insulation.

The cause of currentScript is not defined is in dynamic script loading. Under standard only scripts which are part of initial HTML will be given document.curentScript set.

Hi, This project seem to be the first true modular movement in Web Components.
I been look into way to jailing JavaScript but had yet found any solution that seem promising. This look great for next generation lightweight web component module that is embedded without iframe.

If Google doesn't yet pulling resources to this working group since they also working on Google Caja, which seem to be few that at least certain promising, I am recommend you can refer or pulling collaboration from Lightning System Aura Locker Services or its implementation Open Source Aura Framework

Sorry just bump in your project and giving a shout out. Feel free to close this issue, and get it out of your way. Thanks for the project initiative.

Links to webcomponents.org in the readme.md file and also in the repo description are broken.

E.g.
https://www.webcomponents.org/element/EPA-WG/embed-page
https://www.webcomponents.org/element/embed-page

Is it possible to let htmlContent be 'rendered' as html? ( instead of showing <h1>In Iframe</h1> )

<dom-module>
   <template>
      <embed-page>[[htmlContent]]</embed-page>
   </template>
   <script>
       class TestPage extends Polymer.element { 
           ....
          static get properties() {
              return {
                  htmlContent: {
                         type:String,
                         value: '<h1>In Iframe</h1>'
                    }
              }
          } 
       }
....
</script>

target attribute to reference the links and form inside of embed-page. It is different than scope. Point of target is control over another embed-page instance.. The menu is a good sample. Link would open microapplication in given by target instance( with matching name attribute). For example, contacts in chat or inbox in email.

As jQuery is quite popular in embedded apps, having it declared on top level could create a collusion of embedded and page jQuery instances. + extra code volume.

Current implementation in most heavy demo page delays the full page load for 1.1 second which is too long accounting the basic nature of scripts used for demo. It also does not survive default timeout when runs under debugger in FF.

Microapplication Container loads various resource types and along with loading it needs to transform those resources more than once. As transformations would be aware of syntax and some semantics,
it has a sense to pass AST instead of working with source text. Transformation would either incrementally adding the elements to AST or (optimization ones) replace the content completely. The 1st could reuse initially parsed AST, last could (better?) create new tree and feed data during initial AST traverse.

Formats for AST data:

• Json, actually JS object - 🤢 needs marshalling to/from transformer
• apache arrow. Has sufficient support for programming languages, reuse of data TBD.
• 🤩 xml dom. Could reuse same binary data by huge set of languages which also includes XSLT - only native multithreaded lang in browser.

XML libs also give ability to use streaming processing eliminating the need for keeping whole datasets in memory and threading the pipeline.

In-browser XSLT 1.0 and saxon based xslt transformation are 1st candidates as they give multithreading and streaming out of the box.

Same as XML libs give ability to traverse data in stream and directly via DOM API, transformers could benefit from both ways of data access.

Direct DOM access could be beneficial when there is a need for several passes or altering initial DOM

some rudimentary mapping is already implemented, question is what standard to follow ?
There are some related uses and proposals:

• https://github.com/WICG/import-maps
• https://github.com/WICG/import-maps#community-polyfills-and-tooling
• https://wicg.github.io/import-maps/

https://github.com/open-wc/open-wc/tree/master/packages/import-maps-resolve
https://github.com/WICG/import-maps/blob/master/reference-implementation/lib/resolver.js

• aliases in requireJs http://blog.firsov.net/2017/

The API for scoping is still in drafts, hence there is need for own implementation.

Community have come with own way around:

https://open-wc.org/docs/development/scoped-elements/

Plotly.js uses var d3_document = this.document which leads to

TypeError: Cannot read property 'document' of undefined

polymer cli generates the code which sets windos.define=function(){...} in first script section and use define() call without window in following script section.

Which leads to inability of use polymer generated code as microapplication.

The same pattern often used for global objects access.

While embed-page does provide own instance of window and populates some members as scope variable( document, location, etc. ), the variables assigned to window object are not exposed.

the inline is executed upfront despite the original order is <script src="..."/> <script>...</script>

In order to make the EPA component alive its JS need to be run in insulated context and with insulated browser APIs. It is possible via

• IFRAME , but it will need a layer to run EPA integration API within embedded page
• closure with wrapped window, document and other browser APIs to insulate related data layers from page itself and other EPA instances.

The thread bellow reflects the evolution of thinking around subject and ways to implement.