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.
Related
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.
I'm currently using a NodeJS server. I verify a condition with a if statement. If the credentials are not valid, for example, how to send the user to a specific page?
if (credentials) {
// go to the main page
}
else {
// go the login page
}
You've said you're using ExpressJS. In ExpressJS, you do a redirect via res.redirect:
res.redirect([status,] path)
Redirects to the URL derived from the specified path, with specified status, a positive integer that corresponds to an HTTP status code . If not specified, status defaults to “302 “Found”.
First, you need to establish what kind of authentication you are using. There are a million ways to do this, but if you are less familiar with auth systems, I would recommend using a third-party auth system like Facebook or Google login. Those would generally give you some kind of auth token on login, and essentially you could just check to see if the stored token is there, whether that be in cache, cookies, local storage, etc., and if it has not expired. If all is good, keep going, if not, then redirect to the login page.
If you want to make this more secure, don't write any of credential validation on the client side. Have the client's browser check for the auth token and its recency, then send it to the server. The server would then respond by routing you to the proper page.
Another method that should probably be used in tandem with this would be to check for a valid login on every single page where the user would need to be logged in, as opposed to only having the one page that redirects to either a login screen or where you want to go.
I have a simple web service and I want to add social login with Facebook and Google using Loopbackjs.
I've already done parts of this editing the example found at this link: https://github.com/strongloop/loopback-example-passport and following the instructions at this one: https://docs.strongloop.com/display/public/LB/Third-party+login+using+Passport.
My problem now is that I need to retrieve user information after login, so that every following editing request on the User model can be direct to the owning User entity.
e.g. The User X want to access to my application:
X request for "example_site_address/auth/facebook";
X will redirect to "www.facebook.com/dialog/oauth?response_type=code&redirect_uri=example_site_address/auth/facebook/callback&scope=email&client_id=XXXXXXX";
After his acceptation, he will redirect to "example_site_address/auth/facebook/callback&scope=email&client_id=XXXXXXX";
Then he will again redirect to "example_site_address/success_fb", this link should give to the client the User entity with which he is logged in.
Using Google this problem is solved because I could retrieve AccessToken information from the cookies, find the User who's owning that, and then send back it to the client, so he can store the UserId and every a following request could be like on this User.
Using Facebook I'm not able to do this, because cookies concern login are encrypted.
I'm a really beginner on this kind of application, so it is possible that my strategy is wrong. Could you help me to do this?
LoopBack Example is using a cookie-parser package (see server/server.js). Cookies are signed but you have an access to them via req.signedCookies property.
I have a react/laravel app that currently uses a variable stored in the localStorage to do routes protection.
When a user is authenticated on the server side, front end saves a variable logged-in to true in localStorage. In react, on route enter, it checks if logged-in variable is set in localStorage. if not, redirects to login component.
The problem is that user can just modify their locaoStorage with javascript or in their js console to cheat the UI authorization.
So how should i go about preventing this? Or is there a better approach to protect routes in react? Thanks.
I'm creating a shopify app. I've written express middleware that will take a shop via query parameter so the route with "/?shop=example-shop" will kick off the login flow, from there the user gets redirected to shopify where if they aren't already logged in they do so then "install" the app, approving my apps keys. Then they get sent back to the app where I exchange the code for an access token and do other things like store the user. There's a lot that happens when they come back to the server and I'm having trouble deciding how to test everything. For one I can't even test this route unless all of the returned params are valid (signature, hmac, timestamp).
I'm thinking I could use Casper to login to shopify and follow the flow.
How can I test this very complicated login flow, with valid get parameters?
All the local stuff is easy to test, like database calls. However I can't fake / mock keys and the access token exchange.
In general, the OAuth 2 login flow works something like this:
You make a request to your route.
It sends back a 3xx that redirects you to (in your case) Shopify.
On the Shopify portal, you fill in the form and log in (sending a POST to them). This ends the "Authenticating the user" part.
A 3xx is sent back that redirects you to a different route.
When the second route is hit, it sends a request to Shopify to authenticate the server. Upon successful authentication of the server (now the user and server are authenticated), it's safe for Shopify to return the data, which your second route will receive.
Unit Testing
Think about how your routes would be unit tested.
Your first route receives a GET request, and sends back a 3xx without doing anything else.
Your second route receives a GET request, receives some sort of user object from Shopify, might do something with the user object, and then sends back a 3xx.
So for the first route, you'd really only be testing that the GET request sends back a 3xx. For the second, you might want to test anything the server does with the user object it gets back.
But as you mention, Shopify will only send back the user object if the user and server have been authenticated, and you won't be doing this full fledged authentication with your Unit test. What you'd want to do is mock the response from Shopify! Ie. when the request is made to the second route and you're in a testing environment, instead of authenticating with Shopify, just mock the user object you'd get back and continue to do whatever you'd normally do with that object. If you want to do a true unit test, this is the way to go.
Integration Testing
Alternatively, you might want to do a full integration test of this entire process. There's a lot of ways to do this, but basically you'd go through the 1-5 steps I outlined above. You'd probably want to set up a account with Shopify that is used for this test.