I have one app on abc.website.com that authenticates users using devise with Ruby on Rails. I have to setup a react app on def.website.com that only works if the user is logged in on abc.website.com (abc uses devise)
We have to add a link in the navbar of abc.website.com that redirects to def.website.com.
Any suggestions on what the best way to do this is?
I'm a total ruby noob but good with javascript.
thanks a lot
appreciate the help
Here is one of a solution : Token Based Authentication.
JWT also is a fine idea.
The rails app can also store a cookie (for example use the rails session cookie) in the clients cookie store. This gets sent to the rails app on every request by the react app and you can verify the identity of the user by reading this cookie.
There are very few adjustments needed for this approach (and they would also be required for JWT - which I don't want to badmouth, it is also a viable and good approach).
An upshot of this is that almost no data needs to be stored at the client. Only an ID that makes it easy for the rails backend to identify the user and achieve all needed informations.
On the other side, if you want to store all the data at client side this is also possible.
I would say there is no clear advantage of rails session over JWT or vice versa. But generally this is how it should be implemented: By giving the client the necessary information which then gets passed over to the backend again.
Related
I am currently working on a project whose backend I will be writing using Flask (cannot change that), and the frontend will be developed using React by someone else (cannot change that too). I am currently working on the login functionality and I have a few questions. I am really just beginning backend development, so please excuse me if I have some redundant questions or beginner-level questions.
I am curious as to how the login-system as a whole will be handled, not just in terms of actual login - but more so when it comes to restricting access from non-logged in users.
The tutorials and online courses I have taken on Flask have done one of 2 approaches.
The first approach was using Flask-Login to login a user and ensure that they are logged in as they navigate to different websites. This was pretty straightforward to understand and relatively easy to implement. However, (and please correct me if I'm wrong), this would require all the navigation and redirecting to be handled server-side. Therefore, we would not be utilizing React's ability to create single-page websites (instead relying on hyperlinks from each page to the next), which is far from ideal and something that we'd like to avoid if possible.
The second approach was using JWT tokens. Again correct me if I'm wrong, but we would only be able to check that the JWT token is correct if it is included in an HTTP request, which again makes creating single-page websites not feasible. Another issue with JWT is that the tokens expire fairly quickly (around 15 minutes as far as my research tells me), which is not suitable for our project because it would require users to be logged in for a longer duration. I have read about refreshing JWT tokens, but I would like to know more about the feasibility of such a process given the short expiration time (we would have to do a lot of refreshes).
My main question is:
How can we create single-page websites while preventing non-logged in users from accessing restricted pages?
But also please feel free to give me any feedback or concerns about what I have talked about.
Thank you in advance and sorry for the long post
Just use JWT, you can add the token to the header of the HTTP request and you can set the lifetime (JWT_EXPIRATION_DELTA) of the token - check this link https://pythonhosted.org/Flask-JWT
I'm not much experienced in JavaScript programming or Angular app development, but my general understanding is, when JavaScript reaches the client end, it can be tampered.
I've come across some sample implementation of role-based authorization in Angular app where the user roles are sent to the client on successful login (even though they are using JWT, which is supposed to be "self-contained"). The user role values are then saved on the client side (local storage or variable), and used in canActivate route-guard.
(I'm aware that the values used in canActivate will decide only whether to activate the route and render the component in question, and the real role validation happens on server side when the component code tries to fetch data.)
My question is, can these client-stored values be tampered, or Angular has any ability to provide any code-safety?
Thanks in advance.
Yes.
All code running within a browser, and all the data, is subject to manipulation by the user.
You don't even know it is a browser that is running the code, it could be some other tool designed specifically to subvert your application.
I'm having trouble figuring out how to persist a session on an iOS Cordova app.
I'm using Node.js/Express on the backend and Angular on the front-end. My onboarding processes work properly and everything is dandy until the user closes the application. When it is reopened, the user has been logged out.
I understand WHY this is happening, but I'm having trouble figuring out how to prevent it. Can I use local storage to store and retrieve a cookie? If so, what's the preferred method?
I believe you could use whatever value you want in LocalStorage, as long as you don't get messy with multiple users using the app.. Just check for that value when the app starts and do the magic for user already logged in.
If you want to add more security, perhaps you can save a token in LocalStorage, when the app starts, retrieve that token and compare it against your backend, to check if it's active or not, after that, more coding magic :)
The second option will make the user's workflow a lil bit more slower due to the app request and the server response.
What data should you save? That's up to you, depending on your app, what it needs to 'boot'. If you use a token, you can send the needed data in the server's response.
There should be always something that identifies that user on the server, and not only his username or id, I believe you use something to tell the server that THIS USER is logged in while the app interacts with the server.
Some data about LocalStorage: https://cordova.apache.org/docs/en/4.0.0/cordova_storage_storage.md.html
PS: If you are already using AngularJS, you should check Ionic Framework and ngCordova.
Good luck!
I have a web tool developed, which uses node.js and socket.io. it's a one page website and uses node.js for getting data from social media website and display on the same page. I would like to add a site specific login system for the website but don't want to use 'Express' or 'Passport' as it adds lots of overload to the website while it is not needed.
I am newbie with node.js and would like to know if I need to have a login system made with node.js to maintain session of the logged in user?
Note: I need to maintain session to log user data such as login time, search query and may be heatmap.
Thanks in advance. If needed I can explain specific part of the question in detail.
Using something like Express or Passport (or at least some of connect's middleware) will definitely be easier in the long run (if your app grows), but if you want to go the 'manual' route, here are some starting points:
Cookie Parser: You won't want to send the auth details with every request as a parameter, so you'll want to put the session details in a cookie. You can set cookies manually using headers, or with a node module that wraps the API neatly.
Session Storage: You can put all the "login time, queries and heatmap data" in cookies, but it would be neater to just send a session id in the cookie in each request and save the other data server-side in a database. Options are mongoose, redis, etc.
Since reading the source is very educational, go read connect's cookieParser and cookieSession. It's not a lot of code and the API docs include the actual source, so it's very easy to learn from. Enjoy! :)
From how you are phrasing this question, I believe the overhead from using Express modules (Passport or similar) is the least of your worries ;-)
First you need to figure out which mechanisms you want to use.
For authentication, will you use a username/password combo, or will you be using a third party service like Google, Facebook, Twitter etc ("OAuth" like)? Unless you use some third party service, you also need to handle registration (and possibly verification of email address etc). Even for username/password combos, will you roll your own or use the browser based "basic-auth" mechanisms?
After authenticating you need a session mechanism to store some session token to recognize (and verify server side) that you have been authenticated. They are typically stored in browser cookies, which can easily be persisted for as long as you need, and are verified with each relevant request with tokens in a database on the server side.
And finally, you need a logout mechanism and a "I forgot my password" procedure (which may very well be manual initially...).
If all this is fairly new to you, I suggest trying to use something ready-made first (you mention Passport yourself), and then when you've mastered the basics, feel free to replace it with your own. The "upside" of using Passport or Everyauth is that they cover a lot more options that you realistically will be able to write yourself, so once you've adapted your system to use one of those, adding Facebook logins and similar will be a lot easier (somebody already figured out most of the stuff for your).
To be honest, most of the modules that handle such things in the Node ecosystem are fairly thin wrappers on top of whatever solution you decide to use, so the overhead will most likely not be substantial and you will most likely need a good understanding of the issues anyway to use them. At the other end of the spectrum are ready-made-systems like Drupal etc where everything just works, but then you're somewhat boxed in as far as making your own system.
There are use-cases where rolling your own from scratch is absolutely necessary, but there's nothing stopping your from doing this later when/if necessary (and after you've mastered the basics with the help of code that others wrote).
Best of luck!
When I use Facebook's JS SDK to authenticate my app (using FB.init method) all I need is my App ID. It does not require my app secret and/or app key.
However when I used PHP SDK, it required my app secret (atleast the example I used to learn used the app ID and app secret both).
Is it secure and recommended to use the JS SDK for authentication ? How really does the authentication flow happen with the JS SDK ?
Thanks,
Vineet
I'm looking into how secure the authentication is also - I think things have changed since you asked this q, so perhaps this information was not correct when you asked.
The new version of the JS SDK uses OAuth 2.0. This is well documented - check out the OAuth 2.0 site for details.
Regarding the issue of whether the SDK needs the app secret - I'm having a little bit of confusion relating to this. On the app server side, the libraries indicate that the JS SDK signs the cookies using the app secret (see the function get_user_from_cookie in the facebook-python sdk) - however, it's completely unclear to me how the JS SDK can know the app secret. I'm guessing that it can obtain it dynamically from FB when it talks to FB directly in the authentication process, but I'm not sure.
(Edit: I think that the JS SDK gets the cookie signed with the app secret directly from FB - the JS SDK never knows the app secret).
Not fully answering your q, but perhaps shedding a little more light on how this works.
Another issue to be wary of is not to use the FB user object you get from the client for anything on the server side. This is because it would be really easy for someone make a script which instead of calling fb.api '/me' would send a "fake" JSON user object with another users ID to your app. If you're doing any kind of server side processing of the user then you really need to do some kind of server side authentication as well I think.
It's NOT safe, this is why you have the "Verify Fields" and "Not Verifying the Signature" paragraphs in the Advanced Registration document:
When you request facebook data, we
verify the form fields before
packaging them up in the
signed_request. This lets you assume
that all the data is genuine and saves
you from having to verify things. The
one problem that could arise, is a
smart attacker could change the form
fields and submit them to you, thereby
giving you unverified data.
Read that document for more information, I've also wrote a tutorial (an introduction about the plugin) and showed how to handle the fields attribute coming from client-side.