I need some back end assistance here.
We're building a portal and upon login the user will be navigated to the appropriate landing page where they may find certain files they have subscribed for.
We've been looking at React, Node, Mongo, and Keystone to build this out.
I'm curious to see how one would be able to manually add users and passwords in keystone that would allow them to login initially and be directed to an appropriate landing page.
Thanks!
you could manage this in the state of your application. I can't speak on Keystone but think of it like this.
Keystone has your auth information for users which is tied to a users document in your mongo database. Once a user is logged in / auth'd you can pull the user data in via an api request and then route based on the response at the app level.
We do this currently with redux, react, and a postgres database to route users to pages based on the company they are assigned to.
You can create the user in your model, then you need to implement a custom login page, not the one that keystone provides by default since that automatically will redirect to you to the admin panel.
I think a way of achieve this is implement a custom login page, then in your controller, if the login is successful you can redirect that user to a route defined in the user model.
Related
My app renders components and layout based on user permissions. Permissions are created dynamically. (permissions are basically what are the modules and actions that a user can do.
e.g: The user can delete records, update records, can view settings tab, etc
Permission Keys are coming from the backend. when the user hit the login API.
Should I use context to pass through the component tree?
What if the page refreshes? Then I need to call the API again to get permissions? should I need to store it in the session/local but a user can update and change the data in session/local storage also it is not secure. What should I do?
This is a hypothetical question, so let's say you've got a full-stack web application and there is admin-dashboard in the front-end side.
I, as /NOT/ admin, try to access a route such as /api/admin/dashboard
In the React app, some authentication logic can be done such as if user.isAdmin allow to dashboard else navigate back to homepage
In the back-end side, let's say Node.js, you just res.send('not authorized')
So what I thought is I'm on the client side right, I can take minified js which is derived from npm build of React app, and I don't know but somehow I can revert it back to React App folder structure then there is all the util files, components, hooks and everything.
That means I can manipulate authentication logic like allow everyone to see dashboard and also manipulate the fetching logic that would be if error from fetching, instead of return 'not loaded', compeletely remove fetching logic to the backend and just see me dashboard
So, to my understanding, after some effort, maybe not data and functionality that requires me to speak to backend, i can see dashboard or even all the layout, right?
My question is, can we prevent this to happen in some way?
Or do I need to?
First, As you have use role based conditional dashboard render in frontend, When a non admin user inspect the app and figure out the admin dashboard route, when ever the person visit the page, if any api is giving 401 unauthorized status, then logout or redirect that person to actual page. For a millisecond he will able to see the page.
or
Second, Send your react routing as json from backend api. Backend is way more secure. It will send conditional role base route to react. So, no user can figure out actual route path from frontend any more. So, It is more secure.
I will start with a new large project. I will use Angular2 but I don't know what is the best practice for a project that includes multiple user panels. I need your experiences and advice.
The project will have a landing page. On the landing page also will be a login form. If user information (username-password) are correct the user will be redirected to the panel as the type of the user. If the user an administrator, will be redirected to Admin Panel (dashboard), if not will be redirected to User Panel.
My question is:
What is the best practice to build such kind of project?
Each panel and the landing page as a separate Angular App
localhost (landing page app)
localhost/admin (admin panel app)
localhost/user (user panel app)
Or
All in one Angular App that includes landing page and other user panels in it
localhost (one app with all features)
This project will have many user types (admin, student, teacher, parent for now) and each type will have a panel with absolutely different features.
You can define your routes with the router, and you can use a guard to assign to these routes.
The guard can implement the logic you need for your several user roles.
The basic example is a guard for a route that activates only if the user is logged in. You can go further and then define your roles with a service and then guard your routes depending on the user role from the service.
The official documentation is pretty good : https://angular.io/docs/ts/latest/guide/router.html#!#can-activate-guard
I currently have a React-Redux Application.
I want to create an admin user in React-Redux.
If I create a state with userAdmin true or false will users be able to access the state and change this value? That is to say, is this a secure method of creating such access?
I am using webpack to create a bundle.js, and have a node.js server for serving data that is secured using JWTs.
Furthermore, is there a standard or semi-standard pattern for creating an admin user in a react-redux application?
My thoughts on this are:
Create a separate app for admin user management.
Create a state for the admin user and if that state is true then query the serverAPI for any admin action. But show the admin capability only if that state is true eg. delete other users, view details of users, but do not serve that data without an authorised API call. Then if the state is changed surreptitiously the user can only see the actions but is not able to access the API without the required authorisation.
tldr: your thoughts are correct
You are right in the assumption that the user could manipulate the state of the client side app to escalate her privileges. However, that shouldn't give any useful benefits if your architecture is done right.
Data that only admins should have access to shouldn't be transmitted to a regular user in the first place and changes that only admins should be able to do should only be accepted with JWTs that identify admin users.
Right management is something that has to happen server side. The client app just reflects that in the UI.
I've been able to successfully setup multiple Ember applications with shared Ember Simple Auth cookie based authentication. The next step of my journey is to setup proper redirects between applications. Hear me out.
Scenario A (this works out of the box, yay!)
User tries to access domain.com/deep/link/resource
User is NOT logged in
User is redirected to domain.com/login to login via single sign-on component that uses Ember Simple Auth to save cookie with token
After successful login user is redirected back to domain.com/deep/link/resource via previous transition
Scenario B (this works out of the box, yay!)
User tries to access app-b.domain.com/deep/link/resource
User is already logged in via Ember Simple Auth cookie with token
User can access app-b.domain.com/deep/link/resource route
Scenario C (this is what I need to achieve)
User tries to access app-a.domain.com/deep/link/resource
User is NOT logged in
User is redirected to domain.com/login to login via single sign-on component that uses Ember Simple Auth to save cookie with token
After successful login user is redirected back to app-a.domain.com/deep/link/resource via previous transition on app-a subdomain
Any help or guidance would be much appreciated. I wonder if I can achieve Scenario C with Ember Simple Auth only, or if I need to write custom redirect logic in beforeModel on subdomains, etc.
You'll be able get scenario C working by overriding the AuthenticatedRouteMixin's beforeModel method. That will by default to an (Ember.js) transition to the login route but in your case you want sth. like window.location.replace('domain.com/login') and remember the current URL in a cookie or so. In order to redirect to app-a.domain.com/deep/link/resource after the user logged in you'll need to override the ApplicationRouteMixin's sessionAuthenticated method so that it redirects to the previous URL remembered in the cookie if that's present and falls back to the default behavior if not.
Overall, getting this to work should be pretty straight forward actually following these steps.