If you have a web application with a (react) frontend communicating with a REST API, what is the best way to limit access to the views?
Let's say youre not creating a single page app, you have multiple server side routes all delivering a react frontend. These routes should all be protected via authentication, so basically even the (non sensitive) react frontend shouldnt be delivered to the client. Do you handle this on the frontend on every page? Or does that mean that i might be using the wrong tool? If you do a server side session login you would have to handle the authentication and thus especially the entity layer in two spots (limiting access to views and API). I guess you can propagate the web server login to the API or vice versa, but i'm really unsure of what is the best way to go here.
I really hope the question is not going to be viewed as "subjective".
Related
I'm looking to get some input on the best way to achieve handling different sessions with multiple Salesforce tabs (classic but eventually moving to lightning) with server side Blazor.
I was tasked with creating an application to be framed within a Visual Force page within Salesforce (wasn't a fan of creating a secure iframe architecture but that's besides the point). The application was created as an ASP.NET Framework MVC web application and uses session state for state management upon a successful SSO request.
This iteration, I have migrated the app over to ASP.NET Core MVC and Blazor. With Blazor not being able to guarantee the HttpContext and reliably use session state, and a new request to support different states within different Salesforce tabs, I'm looking for new options.
I know there are multiple ways to go about this such as session storage, JS variables in the layout, C# variables in a parent component, etc. I'm curious which would make the most sense here.
I was leaning towards session storage, which I imagine is scoped to the browser tab and not the Salesforce tab. I assume I'd need to accept a Salesforce Tab Id in the SSO request to store off separate instances of session objects within the session storage, and then store the Tab Id in the layout or a parent component for later use (that is if the iframe will even have access to session storage).
How would others go about this task? Session storage, URL state, Database, variables, some combination of the latter? I'd like to avoid in-memory state to avoid any interruptions with app pool recycling or load balancing.
I'm experimenting with these 2 technologies to make a secure web app [Currently learning React (60%) and Django (<50%). This is intended to be like a medical database, so doctors and nurses enters their patients' information. They need to login obviously. I wanted to implement React-based UI (And not using the classic method to create views from django), so I've found many tutorials just like this one:
https://www.digitalocean.com/community/tutorials/build-a-to-do-application-using-django-and-react
It basically turns Django into a restAPI, and then the React frontend uses axios to retrieve data from the endpoint. Sounds not bad at all (comparing to the native method of rendering data in a webpage from Django), but the problem is that I have no idea on how to make this secure, you know, Django provides an auth system, which is pretty good and secure, I have to say, but in a project with this structure, the auth needs to be done in React, so there many questions appear:
To start with, is it a good idea to make a project of this structure? (If no, then what could be a good one)
If it's a yes, how can I protect the API so only logged in users can interact with it? (What mechanisms to ensure protection)
Yes, this is absolutely a good idea to separate the client application and the backend server application.
You can access the backend through the rest api basically with any frontend framework/app/script.
Customers are able to extend their own applications with the abilities of your backend service.
You can create multiple different frontends that use the same backend or different parts of the same backend via the rest api (multi-branding, reselling). Or you can just swap the frontend framework every second year to a new one.
It's also easier to create different automations by using the rest api.
And the list goes on.
For django rest api auth I would recommend Token Authentication which is already included in the Django REST Framework and for React use this tutorial for implementing the login and the token handling.
And don't forget to use TLS on your servers, and create API documentation. (Example)
Is it possible to build a React Native App with a log-In screen that simulate/mirror a popup window of web-App having in mind that we don't have access neither to the server nor to the database of this web-app?
Thanks
I think the answer will be no, while this might technically possible.
You can of course mirror everything an already implemented login does, from the client side, including the HTTP requests to the server but usually that is very uncommon.
What someone usually does is
either use an existing pattern to talk to a backend service
or implement one (also on the backend side)
In general, you do not want to have any security features implemented in the frontend as it can be manipulated.
I came across this issue when consider the fact that my react-application needs API keys to access a backend it is using for CRUD operations on a secured database:
https://create-react-app.dev/docs/adding-custom-environment-variables/
WARNING: Do not store any secrets (such as private API keys) in your React app!
I want users authenticated into the application to be able to perform these operations without necessarily having the API keys exposed to the end user.
Common consensus seems to be create a mid layer, ie an express server that handles enriching/forwarding the request properly. But at that point, the same issue occurs if I want to authenticate the web app against the midlayer, ending up one way or another exposing the original secured API backend.
Is there a way to guarantee a "handshake" between the front end application and the original secured backend? If I need access to the code base to do so, can I do so via a mid layer instead
You have to disable the CORS in your express server.Thats means except your front end, no other client can send request to your Express server. And then, though your authorizationfor your express server is exposed but its not gonna help unless the request is from your front end app.
I'm new to both angular and web api, I've worked previously on asp.net web forms and java jsp's my question is since angular is pure js framework and web api is used for Http services ,if we build web applications using both these technologies how can session management be handled, can we create session in web api controllers ? If we can, since webapi (REST) is stateless does it violate the principle of REST statelessness , please clarify
Thanks
Angular and WebAPI do not change how to track session in web applications. Usually, this is done with a cookie that is sent with every request. Since cookies follow domains, Angular requests will always send in the cookie (just like they did before).
To answer each of your questions:
can we create session in web api controllers?
Yes, we can access session through HttpContext.Current.Session.
does it violate the principle of REST statelessness?
REST (Representational State Transfer) doesn't have a principle of statelessness. HTTP is a stateless protocol. REST says that calls to the server (using HTTP verbs etc.) should progress state of the application.
I don't have the reputation to comment in response to him yet, but David Tyron seems to be misunderstanding the term "stateless" in this context. Obviously, both the API and the UI using it have to maintain and progress data that can be properly labeled a state, but in the context of RESTful APIs, "stateless" is usually specifically referring to the fact that the API doesn't keep track of the client's state.
The idea behind this is that each request to the API must include all of the necessary UI information to perform the required action. In other words, each call must happen in isolation and independent from each other.
Sessions absolutely violate this principle, though it's probably the most common thing that is used that prevents something from being 100% RESTful.
(On a related note, Cookies still count as stateless since the client is the one responsible for storing that data.)