the service I'm developing consists of chrome extension & web application.
For it I'm trying to create 2 server:
web application server (build by Rails)
API server(build by Django) to receive requests from chrome extension and process user data.
Those application use same database, same user information.
My question is how to authenticate users -- in Rails app, users can sign-up and sign-in via form. But in API server, how to authenticate users?
One solution might be JWT authentication, user get JWT token from Rails server and send token to Django server, and Django server authenticate by JWT authorization.
Is that best practice -- or simply sending username & password is better then this?
Thanks
I honestly believe that attempting to combine these two web platforms is not the best idea. You can read feedback from a similar question here, but basically attempting to combine rails with Django will lead you down a serious rabbit hole where both Rails and Django are going to be expecting to handle the authentication. You can potentially use a different, more simple Python framework, but I think you can potentially achieve the same overall goal with a single Rails application.
If project specifications require Django, then you can potentially try the latter option of username & password to do a database read, and then manually create a JWT functionality. I think it would be really really difficult though to use many of the built in, or even open source solutions, that Django provides, which is why Django could be overkill.
Related
I am building a Ruby on Rails (Rails - v4.2.3 & Ruby 2.2.2) App which consumes an existing REST API.
The aforementioned API is written in PHP.
I need help regarding how to manage the authentication?
On searching through various forums I came across these two gems
https://github.com/lynndylanhurley/devise_token_auth
https://github.com/gonzalo-bulnes/simple_token_authentication
The problem I am facing with both is that they require my app to have a users model configured (using Devise).
However My app is primarily a front end for the Existing REST API, so if I do configure my own User model, I will end up with two Data Stores (One for the APP I make and the other for the existing API).
I wish to consume the external API and not have any native models for my APP.
I believe I can use ActiveResource for this (I need more reputation points to post a link to the gem, sorry I cannot do that right now, I am new to StackOverflow):
However I am not sure how to go about managing the security of the application. More specifically what measures can I take to prevent the authentication information from being viewed in plaintext while it is being transmitted to my API server for authentication?
Thank You.
Use HTTPS on your API. If your external API is using HTTPS then user info wouldn't be sent in plaintext from your rails app.
Don't forget to use HTTPS for your rails app too, as that is more important.
We are building a JSON API on top of our Web application, using JSONAPI::Resources to expose endpoints and Doorkeeper to handle user authentication.
Most of our API endpoints will be exposed only to authenticated users, and Doorkeeper will probably do a great job at enforcing that. But we still have a couple endpoints that will not be authenticated: signup, login, account confirmation, and maybe a couple others.
I am worried that letting those API endpoints completely open will expose us to attacks, in the form of spamming new accounts for example.
Maybe I am worrying more than necessary? Do APIs usually let this kind of endpoint unsecure, and add prevention systems like throttling? (Rack::Attack!!!?)
If not, is signing (or encrypting) my requests before sending them to the API server the right approach?
And if that's so, do you have any recommendation, or preferred approach, in doing so?
I tried to Google keywords like "rails api sign request" or "rails api encrypt request", but I'm not sure the results are pertinent, or which one would be recommended.
The first clients that will talk to this API will be Android then iOS applications, and we might add in the future client-side web applications (at the moment, our web application is monolithic and does not use the API).
How to secure access to rails server which provides REST API access.
We use Devise for authentication.
Our Rails app talks to another Rails server (Service App) and we would like the user to authenticate before accessing the Service App. Should I do it via device authentication token. Kindly advise? What should be done at the service level
https://github.com/plataformatec/devise
https://github.com/lynndylanhurley/devise_token_auth
Well, it depends of your app architecture.
You can use devise to authenticate users at REST API.
But if your Service App is for internal use only, for example it provides data only for another app, you can restrict access by ip, or Basic HTTP auth.
My opinion, that devise is good only for authorising end-users, but not services.
In my opinion, this question is highly opinion based as it stands at the moment.
What is the purpose of the Service App? Does your Rails app consumes frequently from the Service App? Or the other way around? Is it just for logging purposes, like statistics or tag-like resources or critical data like credentials?
From my rule of thumb, if an actual end-user needs to access it to modify a resource (POST, PUT, DELETE) I'd go for token based authentication. If it only needs to read, I might just go with just Basic or none at all, depending on the context.
Either way, I would consider twice if Devise is the precise tool for your own scenario. More than few times I have found myself writing more to actually modify Devise than it would be necessary if I implement my own authentication system. It's not that hard and you learn a lot!
I am reading the Service Oriented Design with Ruby book by Paul Dix and many posts here but am left with many questions surrounding authenticating users and the application.
I want to have api.site.com as a RESTful Rails app serving up JSON. Secure.site.com will be a web app (maybe Rails or maybe PHP) that will consume the service. Also a mobile app such as iPad will also consume it.
So is the first step to build in a level of auth so that only my web app and mobile app can consume the service? Then once the calling app has been authenticated, both these apps will have users who want to CRUD their data so then authenticate them as well?
I've read about Http basic, digest, tokens, oauth and many plugins but am having a difficult time narrowing down the most flexible and reusable way. For now this is simply learning so I would like to stay away from plugins so I can learn the code better.
Can my web app use normal sessions like I'm familiar with and then the mobile use their equivalent to sessions. At that point I still have no authenticated the calling app though. Http basic seemed like I could use it from both, but I didn't see a way for my web app to use a normal login form and logging out seemed like an issue.
I would suggest two solutions for you.
Use a Gem like devise for login system and inherit the devise registration and sessions controller to make it respond to JSON requests.
Create your own simple authentication and use respond to HTML and respond to JSON for separating web and mobile login
Iam not totally sure whether a mobile device maintains a session (please look around) but u can always use a token authentication system if it doesnt.
I have been trying to figure out how to integrate a node.js app into a rails app and having them share sessions. I've so far only been able to dig up sharing sessions between sinatra and ruby on rails via rack middleware. Is it possible to to do this?
I thought of a workaround involving the ror implementing a rest service that "poops" out a guid that node.js can use to create its own session. This solution however requires having model validations ad such stored in two seperate apps.
just wondering if there was a way to integrate them.
and while using a js based webframework like geddy or express is cool, I have alot of existing rails code and 3rd party libraries such as active merchant that I would have to reinvent.
how about using something like memcached to share a validation mechanism, for example set a session in rails and for every message to the nodeJs server a token is given, nodeJs checks on memcached if the token exists and grants or denies based on that. You would of course add the record on memcached from the rails app
Isn't that the same as sharing authentication between two different domains like openid, facebook connect, twitter sign-in.
from rails site do an openid like redirect to node.js with the authentication information encrypted inside the url and vica versa?
I am wondering if it is not possible to use Custom OAuth Provider Strategy from connect-auth and vica versa because connect-auth is "Authentication middleware for connect". I haven't figured the complete details out, but this might be an option?