I want to have Web Components hosted by one site, which another site cannot access the inner DOM or Javascript of. Exactly like with iframes, but which can be rendered inside the HTML better, for example sizing to incorporate their content etc.
There have been many discussions about this but in 2019 when I ask this, is anything implemented to do this?
EDIT: Let me be totally clear - I want the JS for the component to be served from our servers, requests to our server to be done from the component’s JS, render stuff in the component, but not let the enclosing site get it or put a trojan horse in the component. I am fine w the encloing site providing CSS but no HTML or JS. Can this be done?
How would it communicate with the component, analogous to postMessage?
Finally, is it possible for the COMPONENTS JS to access the outer containing website’s DOM and thereby find other components and communicate? This last one ain’t possible with iframes on another domain.
Simple answer: No.
Web Components Do not isolate JS. Just DOM and CSS.
But you can put all of your JS within your class, or in an ES6 Module, or in an IIFE and that would isolate it.
But I doubt that Web Components will ever be a 100% replacement for <iframe>. Nor do I think they were meant to be such.
I would not be surprised if the <iframe> were to become deprecated and eventually removed from browsers.
UPDATE
Keeping ALL of the JS code inside your component's class or inside an IIFE will somewhat protect the code. The HTML and CSS are already sand-boxed inside the component. If your code was in an IIFE or in an ES6 module then other code would have to have access to the source file and be able to modify it in order to change it.
Communication from the outside with the component is done by the outside code calling functions of the component or setting properties and attributes of the component.
Communication from the component to the outside is traditionally done by dispatching events. Talking directly from one component to another is a messy option and really should be avoided. It is up to the parent code to listen to events from all its children and then call functions or set properties/attributes on other children.
If you use shadowDOM then the enclosing site can only change the CSS of your components if you make certain aspects of the CSS available to them. This is done either with CSS Varaibles or by using <slot> to allow the enclosing app to place their own HTML/CSS inside your component. This could open you up to some things you may not want though.
The code that is in the class, or in an IIFE can always access anything in the DOM. Remember that JS is not sand-boxed and can do anything any other JS can do. But it is more difficult, though maybe not impossible, for the enclosing app to make changes to your component classes. Make sure your classes are frozen to prevent sub-classing.
One other thing to know is that if you have someone else loading their website from their server and then loading your component files from your server then you may have CORS problems. Especially if your code tries to load data using XHR/Fetch, then you may have CORS issues.
Related
I’m new to React, and I have trouble with finding best solution for my app.
My current (Node.js+Express+Handlebars) app has one main menu with place where I render HTML received from AJAX request made after click on menu element. Then all actions inside this element are done by proper JS script. I wanted to improve it by using React, but I have problem with permissions management.
Currently, after authentication, handlebars receive list of files which user should load and render it as src in element. If user has access to only 5 of 20 modules, he can access only proper JS files. Also, he can’t access HTML he don’t has access to.
How to manage it in React? I want to have one interface for all users, but I don’t want to store logic for all components accessible for every user. I was thinking about something like AJAX loading components for React, but how to manage it?
Is it even possible? As I understand (maybe wrong), all React components are compiled from separated JSX files to one main.js, so is it possible to add separate files with other components?
I believe that the issue that you have encountered is a crucial step on the long stairway of making something great. The solution to your problem is the balance of all the present factors and consolidation of them to cooperate on a mutually beneficial basis. I hope that solves your problem
I am on a team that is interested in using ui:include to embed external resources in a HTML document. While investigating how to do this, I came across this post: JSF Facelets how to include external html?
BalusC clarifies that is the wrong tool for embedding external resources in a HTML document and suggested using iframes instead. My question is: why is it the wrong tool?
The team I'm on is especially concerned about security. The content is all going to be our own, but there is a concern about cross-site scripting when communicating between iframes. I've read that there are security benefits to using iframes, as well.
Since the answer likely depends on the use case, I will describe mine:
We're using a docking framework called wcdocker (http://docker.webcabin.org/), which allows panels to be added as divs (planning to use ui:include) or via iframes.
From what I've read/experienced so far, my main concern is that you would have to load the entire page for a given panel, even if the user might not actually open it. There will be multiple dockers, and each will have about 50 panels that can be opened. I am concerned that the client will be overwhelmed, compared to a simple link that may/may not be opened in the given docker.
My second concern is with conflicts if the user attempts to open the same panel twice (same ID tags, omnifaces socket conflicts where the backing bean declares a PushContext for a viewscoped recipient, etc.). I have read workarounds for some of this, sounds like a headache...
Their main concern is regarding communication between panels and cross-site scripting attacks. They believe the user's panel communication should be done directly on the client side, so that the server does not have to be hit at all. I believe the user's panel communication should be done on the server side via a custom publish/subscribe approach (not via JMS) where panel A publishes to a custom Java "topic" object and panel B subscribes to that topic.
For context, there will be a maximum of 50 users at a time, and the web application will be fairly complex.
After a lot of research, there is at least one issue with my question: our content will not be "external" at all. It will be content that resides on the same server as the main application.
Anyway, it seems that at least one concern with iframes is having too many view states. This thread is the most relevant to that problem: JSF multiple views limit. There is a limit to the number of views (15): (ViewExpiredException after upgrade to jsf2)
You can increase that limit in the web.xml file, but it may be difficult to identify the right number for the problem described above.
In another thread, BalusC indicates that ui:include is the best way to put an xhtml inside another xhtml (How to include another XHTML in XHTML using JSF 2.0 Facelets?). However, ui:include does not appear to be ideal for dynamic content. With wcdocker, a panel may be added/removed at any time. It may be worth using jquery's load method as an alternative. See this thread for more information, even though it's for PHP's ui:include: Best way of loading/including content? (jQuery's load() vs. PHP's include())
For anyone interested in using wcdocker in a JSF project while avoiding iframes, this code is a good starting point:
myDocker.registerPanelType('My Panel', {
onCreate: function (myPanel) {
var $mydiv = $('<div id="div1"></div>');
myPanel.layout().addItem($mydiv, 0, 1).css('text-align', 'right').stretch('1%', '');
myPanel.on(wcDocker.EVENT.LOADED, function() {
$("#div1").load("thepage.xhtml");
});
}
});
Finally, you may still run into an issue with conflicting id's, particularly if you load the same page twice. This thread may help you to resolve that concern, and it may even be wise to determine ID by a url parameter: Avoiding duplicate ids when reusing facelets compositions in the same naming container
I'm an old web developer, i'm used to html, css, js (jquery) and using a server side language like Java, Cold fusion or PHP.
Now for the life of me i can't find a good explanation or a how to get started. It just doesn't make sense and i've spent the last 3 days watching tutorials and reading books. This isn't to complain, but to ask a favor. Someone please explain to me how this architecture is setup. In the past, you would have an html file and inject some placeholders which would be filled in by your server side language.
What's the structure now? I have create a Ubuntu server, i have installed NodeJS and it's associations, i created a reverse proxy and installed nginx as my server. PM2 is my process manager for NodeJS apps. Am i on the right track so far?
If so, where does reactjs, reduxjs, babeljs, what is webpack for npm? What is my next step, i'm so confused that i don't know what all of these things are. In particular what is the difference between reactjs, redsuxjs and bablejs and any others, are these all just front end libraries or? What's the npm webpack. Then there's redux and react-redux, what? Thanks for the clarification.
My goal
I want to learn how to make a single page application and takes advantage with as much of bootstrap as possible. I thought react would be the way to go but i'd really appreciate some clarifications and not just a copy-paste from their website descriptions. Thank you guys/gals.
First of all, there isn't a short answer to your question. Each of the subjects can be delved into for days, weeks, or months to understand and master. I will try to use metaphors for all related topics in your question.
Q: What is Babel and why do I need it?
JavaScript has evolved over the past few years. A lot!. JavaScript today has so many new words and sentence structures that old browsers simply can't understand without a translator. Babel is that translator. Modern browsers today (Chrome, Firefox, Edge, Safari) can natively understand most of that modern version of JavaScript, or as cool kids call it ECMAScript2015, or ES2015, or ES6, etc.
Even so, ES(JavaScript) is constantly evolving. New features are being added in stages and babel is keeping up with these stage features, literally translating all these new features into plain old JavaScript that all browsers, regardless of age, can understand. You can play with babel and see what it does here: https://babeljs.io/repl/
Q: What is React?
React is just one of many modern front-end frameworks to help you display your data in an efficient way.
If IKEA produced LEGO for developers, it would be called React. React let's you create LEGO blocks (called components) and put them together to create an app. React components can be purely presentational(or 'dumb'), meaning they will simply return some HTML, or they can be 'smart'. Smart components can have something called a state.
If we go back to the LEGO analogy, the state would be the engine in a LEGO Technics set. If a component was a plain old LEGO car, it would need some outside help to get it moving forward. You push the car with your hand and it moves forward. With a smart component, or a LEGO technics engine, your LEGO Technics car can change its state from resting to moving on its own when the engine starts, intrinsically pushing the car forward from within. So whenever the state changes, your car REACTS and changes. The same goes for a component. React will watch for changes in the state of your component and whenever there's a change (usually triggered by a user event) the component will update. React components can be written in plain old javascript, but ES6 is encouraged, and makes your life as a React developer a lot easier. Thus, you will need a translator, like Babel, to make your React app understandable in the browser.
Q: Redux?
Ok, I will simply stop you here and tell you that at this point you don't need Redux to create a React app. Redux is a library that can be used in combination with any framework or on its own with vanilla JavaScript. What Redux does is give you the ability to abstract your application model or data away in something Redux calls a store. A store can be anything, an array, an object, literally anything. Redux's job is to update that store anytime it receives and action.
Let's imagine Redux is a living person called John. John is given an empty cup (the store). Each time John is told 'pour water', John will grab the cup and pour some water in it. The 'pour water' command is our action. John can listen for other actions, for instance 'empty cup'. Each action goes through a processing unit - John's brain (the reducer of the actions). If John was brainless, he wouldn't be able to execute any of the actions. When John receives a 'empty cup' command he throws the water away. You can teach John however many actions you want, and you can give John a different store to execute those actions on. The important takeaway here is that John has a store(the cup), a reducer(the brain) and is given some actions to execute. So the action, goes through the reducer and based on what the reducer decides, it updates the store. So in JavaScript terms the reducer is a function, which takes an action and returns a store. The action is a plain javascript object, which has a type property ('pour'), and it can also have some payload ('water'). So basically you can tell John, 'pour water' in the cup, where pour is the action type and the payload is water.
Q: React-Redux?
Think of react-redux as a scotch-tape that lets you fuse react and redux together, so that each component can send an action to the reducer, and each component can have access to the store.
Q: Webpack?
So with the above example we already have several libraries. Babel, React, Redux, React-Redux, and who knows how many other libraries, assets, files and what not you will need in your project. Probably what you are used to is importing each of them in your index.html using the script, image, link tags. Well, overly simplified, webpack does that for you! Whenever some module in your app depends on another module, asset, or anything else, webpack will recursively look for all dependencies and put them together in one file. You simply import that one file in your index.html and you forget about it. Webpack can do many other things for you, but that's the gist of it, hence why it's called module bundler.
Whew, that's about it. You are a real hero if you got this far, and I admire your patience.
P.S.
A really great (and funny) article to help you get up to date with all these libraries and frameworks is this one:
https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f
As you mentioned that you have worked on HTML, CSS, JQuery and JAVA. It will not be difficult if you understand the need of Reactjs and Redux. If you are using plain javascript or jquery. It will be difficult for you to maintain the code as the size of application will increase. With the help of react js code will be easy to maintain at client side.
Example:
React
Suppose you are creating an e-commerce application which include products, selected product description, shopping-cart, stock-availability of product. If your application is single page. Page will not refresh. You can use react to implement this e-commerce application. You can create components like ProductDetailComponent, ProductDescriptionComponent, ShoppingCartComponent, StockAvailabilityComponent. You will inject all the component in the main component. In this way your code will be more modular at client side. Suppose ShoppingCartComponent needs PriceComponent, BasketComponent. You can use these component inside ShoppingCartComponent. In this way you have component inside other component. If you need to use ShoppingCartComponent in other pages. You simply need to import that component in that page. In this way you can reuse existing component.
All the component will maintain there own data in this way component will not be tightly coupled and can be use at multiple places in our application
Redux
Redux is not related to React. You can use redux with angular as well. Benefit of using redux is you want to share some contextual data across component like user information you can use redux so that user information will be available across component. No need to make additional servder call to get that data. So redux is providing client side caching.
One more benefit of using redux as store is that we can maintain single copy of data. If any component change the data all the component will get notified that data have changed. In our shopping cart example product selected by user can be maintianed in redux which can be used by all the component.
Data sharing between parent to child component
You can pass data from parent component to child component with the help of props as in case of ShoppingKartComponent you need to pass some data to Price component you can use props. You can also pass function as props to child component which child component can call to notify parent component with updated data.
I would like to do the initial render for my React application on the server side, but am having trouble importing and using React components without using something like babel/register (which is not suitable for production).
I would rather not have to compile my server side code for production, but would like to load an node-suitable React component to send to the client via res.send(React.createElement(Html)).
When I run this I get...
Unexpected token <
I assume this is because my components render method returns <!doctype html>...</html.
Is there a way I can have Node render a React component without having to use babel/compiling code before deploying?
Is there a way I can have Node render a React component without having
to use babel/compiling code before deploying?
No. Since JSX isn't real JavaScript, you need to transpile it at some point, either ahead of time (in a build script) or at run time (using babel-register).
Personally I ignore babel's advice to not use babel-register in production. It works just fine, I always cache + prime responses so performance isn't relevant. I'm open to hearing why transpiling with babel-register is bad though.
Short answer, yes.
this is from the official docs:
ReactDOMServer
The react-dom/server package allows you to render your
components on the server.
ReactDOMServer.renderToString
string renderToString(ReactElement element)
Render a ReactElement to its initial HTML. This should only
be used on the server. React will return an HTML string. You can use
this method to generate HTML on the server and send the markup down on
the initial request for faster page loads and to allow search engines
to crawl your pages for SEO purposes.
If you call ReactDOM.render() on a node that already has this
server-rendered markup, React will preserve it and only attach event
handlers, allowing you to have a very performant first-load
experience.
ReactDOMServer.renderToStaticMarkup
string renderToStaticMarkup(ReactElement element)
Similar to renderToString,
except this doesn't create extra DOM attributes such as data-react-id,
that React uses internally. This is useful if you want to use React as
a simple static page generator, as stripping away the extra attributes
can save lots of bytes.
However, if you want to use JSX you have to use babel, otherwise, you can use Reacts JS Syntax.
Here is a link to an example:
https://github.com/mhart/react-server-example
I am running into a problem. I want to host an external page securely. Meaning, no JavaScript in the iFrame. Or it only execute safe code, such as change the text of its page or set the color of its page. And I want to keep CSS alive.
They should look the same from the source, but, no melacious code running behind. No ActiveX, no Flash, no Plug-in. I want them look correct without all the security compromise.
I have tried jQuery load(), but, it only works for internal pages, not external pages. And the CSS in that DIV overwrite my site's CSS, which is not what I wanted.
I am looking for an isolated frame like iframe. But, without security problem. Is this possible?
HTML5 now has a 'sandbox' option for iframes.
This will allow you to block code inside the iframe.
You can learn more at:
https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe
You can create a server side stateful proxy, like a php script that read the remote page and clean whatever you don't like. Not a really simple thing to do, but I'm afraid there is no really easy way around.
I mean, for instance, you create proxy.php:
<?php
$remote = file($_GET['remote']);
// .. filter whatever you like in $remote then print it
And then link to a site using
<iframe src="proxy.php?remote=http://www.example.com"></iframe>
This is not a complete example, just a way of showing my idea.