Building a restful web application using react and having multiple roles - javascript

I'm creating a single page web application that needs to be 100% restful (first time doing this). So, I'm having trouble to decide how I'm going to render the UI for multiple roles using react.
There's going to be a regular user and an admin, after the login/authentication, the server is going to redirect to the main application page, and there is going to be a menu. The thing is, the admin menu should have an extra option, so I'm thinking on should I handle this.
Should I have two different files for the redirect (user.html / admin.html)? The downside would be that I will probably have a bit of duplicated code, because one of the bundles will have everything the other one has, plus an extra component.
Or maybe a component that defaults to none and then if it's an admin it shows itself? The downside would be that if the user has some JS knowledge he could search the code and see what an admin could do (of course there would be authentication in the server to prevent anything from actually happening).
I was also thinking in getting the menu list through a json, and when I click the extra option, it gets the script with the components that should appear, and then I somehow do a ReactDOM.render with the result (don't even know if that's possible, maybe I'm overthinking). Also I've heard about a React-Router but didn't found enough information, maybe that's what I need?
Any ideas/examples on how this is properly done would be really helpful. Thanks in advance.

Definitely don't duplicate your code. First I'd ask, is there really a problem knowing what an admin is capable of? I wouldn't personally worry about that.
React Router would be used for client side routing, and you definitely want client side routing if you're going for a proper React app. You only use the server for initial App route, and then API calls, essentially.
It is certainly possible to pass back arguments to feed into the button component. Your props could contain a 'buttonList' property that has all the arguments necessary to render the button... But that's only really feasible obfuscation if that button's operation is simple, and that's as far as the admin functionality goes. Writing a generic component that takes in specifics by arguments, which can certainly be passed in from the server, is definitely the React way to do this.
What exactly you need to hide from users and how important that is determines if that will truly be enough, however.

Related

Connecting the components in Angular

I'm trying to develop a website in Angular. My website happens to be a Multi-Page Application (MPA), where different pages have been developed as different components. I have developed those pages of the website, I was just wondering how can connect those components/pages together like on a button click, the user should be directed to another page, etc.
Also, it would be really great if anyone could provide any references to some resources or tutorials where they teach us how to develop Multi-Page Application (MPA) with the help of Angular. I searched online for quite a while and didn't find anything since Angular is mostly used for Single Page Applications (SPA).
Any help would be highly appreciated. Thanks!
In your scenario it is really important to have some kind of state saving as a SPA does lose its state on hard reload i.e. CTRL+R.
A common approach would be the use of the localStorage to preserve your data that you need to restore the state, but the downside of it is the security as it can be viewed from the devtools.
Another approach would be the use of cookies which requires a backend. I think this is straight forward and commonly asked how to implement cookies.
That's the same approaches how other SSR (server side redered) pages are handle its state.
Additionally:
I think I kinda guessed your problem as you just have different component on different routes. Angular is a SPA, but this does not mean it cannot change the route. It will change the route, but without reloading the browser. There you can reach other components. More about that I would recomment to read this Tour of Heroes example:
https://angular.io/guide/router

How to achieve security and hiding code from unauthorized user on web page?

I'm creating a statistics web page which can see sensitive information.
The webpage has a sort of table which has massive data in it, editable and stored in Server's database. But It needs to be hidden before the user got proper authentications(Like log-in). (Table itself and it's code too). But I found that most of the questions in stack overflow say it is basically impossible. But when I see lots of well-known websites, it seems they are hiding them well. So I guess there are some solutions to the problem.
At first, I build a full-stack of React - Express - Node - MariaDB toolchain.
The react client is responsible for rendering contents of a webpage and editable tables and request for submitting edited content.
The node with express are responsible for retrieving data from DB, updating DB (Provides data to manipulate from client-side -- that's all)
It comes to a problem when I'm considering security on client-side code. I want to hide all content of the page (not just data from the server, but also its logic and features)
To achieving my goals, I consider several things, but I doubt if it is right and working well if I create.
Using Serverside rendering -- Cannot use due to performance reason and lack of resources available
Serverside rendering can hide logic from the user cause it omits the only HTML from the server and all actions are submitted to the server and the server handle the actions and provide its result.
So I can provide only the login page at first, and if login is successful, I can send the rest of HTML and it's logics from the server.
The problem is that my content in the webpage is massive and will be interacted with the user very often, and applying virtualization on my table (by performance reason), it's data and rendering logic should be handled by the web browser.
Combining SSR and Client-Side Rendering
My inspection for this is not sure, I doubt if it is possible.
Use SSR for hiding content of the site from unauthorized users, and if authorized, the web browser renders its full content on demand. (Code and logics should be hidden before authorization, the unauthorized user only can see the login page)
Is it possible to do it?
Get code on demand.
Also my inspection, this is what I am looking for. But I strongly doubt if it is possible.
Workflow is like below
If a user is not logged in:: User only can see the login page and its code
If the user is logged in:: User can see features of the page like management, statistics, etc.
If the user approaches specific features:: Rendering logic and HTTP request interface is downloaded from the server (OR less-performance hindering logic or else...) and it renders what users want to see and do.
It is okay not to find ways from the above idea. Can you provide some outlines for implement such kind of web page? I'm quite new to Web Programming, so I cannot find proper ways. I want to know how can I achieve this with what kinds of solutions, library, structure.
What lib or package should I use for this?
How can I implement this?
OR can you describe to me how modern websites achieve this? (I think the SAP system quite resembles with what I wanna achieve)
Foreword
Security is a complex topic, in which it is not possible to reach 0 threat. I'll try to craft an answer that could fullfil what you are looking for.
Back end: Token, credentials, authentication
So, you are currently using Express for your back end, hence the need to sort of protect the access from this part, many solution exist, I favor the token authentication, but you can do something with username/password (or this) to let the users access the back end.
From what you are describing you would use some sort of API (REST, GraphQL etc.) to connect to the back-end and make your queries (fetch, cross-fetch, apollo-link etc.) and add the token to the call to the back end in the headers usually.
If a user doesn't have the proper token, they have no data. Many sites use that method to block the consumption of data from the users (e.g. Twitter, Instagram). This should cover the security of the data for your back end, and no code is exposed.
Front-end: WebPack and application code splitting
Now the tricky part, so you want the client side not to have access to all the front-end at once but in several parts. This has 2 caveats:
It will be a bit slower than in normal use
Once the client logged in once, he will have access to the application
The only workaround I see in this situation is to use only server side rendering, if you want to limit to the bare minimum the amount of data the client has on your front end. Granted it is slow, but if you want maximum protection that is the only solution.
Yet, if you want to still keep some interactions and have a faster front end, while keeping a bit of security, you could use some code splitting with WebPack. I am not familiar with C so I can't say, but the Multiple page application of WebPack, as I was mentionning in the comment, should give you a good start to build something more secure.
First, you would have for example 2 html files for entering the front end: one with the login and one with the application. The login contains only the Javascript modules that are for entering the application and shouldn't load the other Javascript modules.
All in all, entrypoints are the way you can enter the application, this is a very broad topic that I can't cover in this answer, but I would recommend you to follow WebPack's tutorial and find out how you can work this out.
I recommend the part on code splitting, but all the tutorial is worth having a look.
Second, you will have to tweak the optimisation module. It is usually a module that tries to reduce the size of the application by merging methods that are used by different parts or that are redundant: you don't want this.
In your case, you don't want un-authenticated users to have access. So you would have to probably change things there (as well another broad topic to be covered in a single answer, since you would have to decide what you keep for optimisation and what you remove for security), but here is the link to the optimisation module and a heads up, you will have to modify the SplitChunksPlugin not to do this optimisation.
I hope this helps, there are many solutions are hand and this is not a comprehensive guide but that should give you enough materials to get to what you need.

Simple push server for prototyping

I want to make a live prototype to demonstrate transactions between two users in different browsers. It should keep the state of the UI in sync between two sessions when each user performs an action. For instance: when one user presses purchase in one browser window, the other user should see that the item is marked as sold in another.
There's nothing new about this, except that I need the absolute minimum solution to fake this behaviour in order to be able to iterate quickly to optimize the flow before starting the actual implementation.
I was thinking Flux and React, or maybe node, but I'm completely new to these frameworks.
Does anyone here have a good suggestion to the best way of approaching this without ending up building a full application? Or maybe to direct me to good starting points?
My suggestion is a NodeJS-ExpressJS-SocketIO combination solution.
It might sound scary if you don't have experience with any of those, but SocketIO is one of the libraries I usually describe as magic.
Just look at the example of the SocketIO website (which already includes everything to run) example instructions and the code of the example
I never used react so I can't say anything on how simple it is to do using it. but the big magic here is actually SocketIO. it might be usable inside react.

How does React.js + middleman work for caching and SEO?

I have been exploring react.js lately and using it in combination with middleman. I really like middleman because it serves up static assets that are easy and fast to host. It also allows you to just cache the entire page as well.
Now my ideal goal is to have the user come to my site, serve up the static assets and then have react populate the dynamic data. This seems great but then SEO becomes a problem. Fortunately react comes with server side rendering, but it's not entirely clear how it works in relation to page caching.
So from my current understanding when the server gets hit with react, it only creates a string of the html with the initialize data put into. Generally from examples the data populated is empty. It then gets recalled when the client hits and fills in the api based data and populates the html. Although I don't understand how this is SEO friendly, apparently it is.
Then I realized that I should be able to still cache the entire instance that react creates with the string, serve that up, and then react can still populate it while being seo friendly. Does this work like I want it to or where in the react lifecycle does this not work?
Yes, you can absolutely cache the generated markup string.
The only thing you need to be careful of is that the props you pass on the server should match the props you pass on the client exactly, so that the initial rendered markup matches, or else React is forced to throw away the server-rendered markup and start from scratch. (The development/uncompressed version of React will give you a warning if the markup doesn't match.)

Is there a good approach or metric for determining when the one page backbonejs app needs to be refactored

I have build a basic backbonejs application and it is one page now handling login, list view and detail views.
I now need to add more business objects to be viewed listed and edited, and I was wondering if there is a best practice on when to move beyond the one page?
BTW it is backbonejs on the front, nodejs and express is on the back
Not really.
You can build the entire thing as a single page app using a router to handle the dispatching between all the various views.
You might want to make "namespace" pages, so like /auth/ is a file that loads just the auth parts of your site, /posts/ might be all the blog posts, etc.
This way you're not loading a ton of javascript into the browser in case someone doesn't never need to use a certain function.

Categories