Im new to backend dev, and I have a full fledge working React app that GETs,DELETEs and PUTs data using a fake server. Now I need to use an actual backend and I was thinking of going with Firebase as it seems really convenient. However I saw some examples using Firebase directly in the React app, and some using Node.js to do the work.. Could someone please tell me whats the best way to go with this? If there's an easier way to create REST API using express/mongo, I am also open to those :)
You have to keep in mind that anything you do from the frontend will be visible to the user, so communicating with Firebase from React will be a bad idea at least for anything involving sensitive information (passwords, credit card info, etc.). Just because you can do something doesn't mean you should. Use a Node backend and use that to communicate with your DB and other services.
To address the last part of your question, it is possible that Firebase might be more than you need. A simple setup with Express and MongoDB might be easier. MLab has a pretty good free sandbox database-as-a-service that requires very minimal setup.
I think firebase can also be a good fit, you can use Firebase auth to manage authentication and Rules in the Realtime database or in Firestore to prevent not authenticated users to manipulate your data https://firebase.google.com/docs/database/security/ And to get the best out of Firebase I would recommend using the SDKs but you can also use the REST API https://firebase.google.com/docs/reference/rest/database/
Also if you want to have functionality on the backend you can do so With Firebase Admin SDK https://firebase.google.com/docs/reference/admin/
From my point of view that is one of the advantages of firebase, you can get con going really fast without having to worry about managing infrastructure.
Related
I'm working on my first web app using ReactJs and have the frontend pretty much done. Now I want to be able to pair the user's data with their username so next time they log in, everything will be exactly as they left it. The user's data is currently all in a JavaScript object so I think I want to save it as a json file. However, I have no clue how to even start this.
My first issue comes with creating the login system. Obviously I cannot just store the username and password in plain text so I would need to encrypt and decrypt it somehow. However, I am currently hosting my site on Netlify so I would need to pass that information over there somehow and the only way I can think of is by adding it to my GitHub repo which is public so anyone can then see my encryption algorithm.
I'm not even sure if this is even how you do it since I've never done anything like this before. Does anyone know where I should start? I don't need something super sophisticated just reasonable.
Probably you can use google's firebase and firestore services. They have an amazing documentation on their website too and there's plenty of resources online. google for firebase authentication tutorial and you'll find a whole lot.
I think from searching the web this is not technically possible but I want to ask again in case I'm missing something.
I have an app that uses Firebase. Reading and writing is locked down through security rules for authorised users only but there's certain information I want unauthorised users to be able to access (so I don't have to put a login wall in front of them, influencing churn).
What I want to know is, is there any way of locking down this read access that only my app can call the DB? I know I can lock down domains to prevent someone writing localhost scrapers but what's to stop someone cloning and re-skinning an app and pointing it to the same back end? Is it possible to achieve this using your certificates fingerprint?
There is no way to limit access to your database to just your app. That just doesn't match with the cloud-based nature of the Firebase APIs. Anyone that knows the URL of your database can in in principle access it, and security rule are the way to ensure all access is authorized.
Note that security rules are not an all-or-nothing approach: you can require sign-in for some parts of your database, while leaving other parts publicly readable. But you can't make the publicly readable parts only be readable by your own app.
Some previous questions on the same topic:
how to make sure only my own website (clientside code) can talk to Firebase backend? (pretty much my go-to answer for this)
How to allow only my app to access firebase without a login?
Restrict Firebase database access to one Android app
How to allow only my app to access firebase without a login?
Update: since May 2021 you can actually restrict access to just users of your App by implementing Firebase App Check.
I have found a solution that maybe helps you or anyone that have a similar question. I answered it in this question:
Restricting Cloud Firestore to a specific domain
I'm working on a React-Redux web-app which integrates with AWS Cognito for user authentication/data storage and with the Shopify API so users can buy items through our site.
With both SDKs (Cognito, Shopify), I've run into an issue: Their core functionality attaches data behind the scenes to localStorage, requiring both SDKs to be run client-side.
But running this code entirely client-side means that the API tokens which both APIs require are completely insecure, such that someone could just grab them from my bundle and then authenticate/fill a cart/see inventory/whatever from anywhere (right?).
I wrote issues on both repos to point this out. Here's the more recent one, on Shopify. I've looked at similar questions on SO, but nothing I found addresses these custom SDKs/ingrained localStorage usage directly, and I'm starting to wonder if I'm missing/misunderstanding something about client-side security, so I figured I should just ask people who know more about this.
What I'm interested in is whether, abstractly, there's a good way to secure a client-side SDK like this. Some thoughts:
Originally, I tried to proxy all requests through the server, but then the localStorage functionality didn't work, and I had to fake it out post-request and add a whole bunch of code that the SDK is designed to take care of. This proved prohibitively difficult/messy, especially with Cognito.
I'm also considering creating a server-side endpoint that simply returns the credentials and blocks requests from outside the domain. In that case, the creds wouldn't be in the bundle, but wouldn't they be eventually scannable by someone on the site once that request for credentials has been made?
Is the idea that these secret keys don't actually need to be secure, because adding to a Shopify cart or registering a user with an application don't need to be secure actions? I'm just worried that I obviously don't know the full scope of actions that a user could take with these credentials, and it feels like an obvious best practice to keep them secret.
Thanks!
Can't you just put the keys and such in a .env file? This way nobody can see what keys you've got stored in there. You can then access your keys through process.env.YOUR_VAR
For Cognito you could store stuff like user pool id, app client id, identity pool id in a .env file.
NPM package for dotenv can be found here: NPM dotenv
Furthermore, what supersecret stuff are you currently storing that you're worried about? By "API tokens", do you mean the OpenId token which you get after authenticating to Cognito?
I can respond to the Cognito portion for this. Your AWS Secret Key and Access Key are not stored in the client. For your React.js app, you only need the Cognito User Pool Id and the App Client Id in your app. Those are the only keys that are exposed to the user.
I cover this in detail in a comprehensive tutorial here - http://serverless-stack.com/chapters/login-with-aws-cognito.html
I'm developing a new web site that will be a single paged app with some dialog/modal windows. I want to use backbone for frontend. This will call backend using ajax/websockets
and render the resulting json using templates.
As a backend I'll use nodejs express app, that will return the json needed for client, it'll be some kind of api. This will not use server side views.
Client will use facebook, twitter, etc. for authentication and maybe custom registration form.
Client static resources, such as css, js, and html files will be handled by nginx (CDN later).
Questions that I have now:
How can I determine that a given user has the right to do some action in api(i.e. delete a building, create new building)? This is authorization question, I thought of giving user a role when they login and based on it determine their rights. Will this work?
Similar to the above question, will this role based security be enough to secure the api? Or I need to add something like tokens or request signing?
Is this architecture acceptable or I'm over engineering and complicating it?
Passport is an option for the authentication piece of the puzzle. I'm the developer, so feel free to ask me any questions if you use it.
I thought of giving user a role when they login and based on it determine their rights. Will this work?
Yes this will work. You can check for a certain role on the user after it's been fetched from the server. You can then display different UI elements depending on this role.
Will this role based security be enough to secure the api? Or I need to add something like tokens or request signing?
It wont be enough. Anyone could hop into the console and set something like user.admin = true. In your API you'll need to validate a user token from the request, making sure that the related user has the appropriate permissions.
Is this architecture acceptable or I'm over engineering and complicating it?
At the least you should have an API validation layer. That would make a decent enough start, and wouldn't be over-engineering.
For the authentication part of your question i would use everyauth which is an authentication middleware for connect/express. It supports almost every oauth-social-network-thingie.
For role management you could give node-roles a try. I didn't use it myself but it should help you out, because it checks the role on the server side. Of course that is only useful if your API is implemented in node.js. If that's not the case, you have to "proxy" the API calls over your node.js app.
I hope I could help you! :)
I'm new to Django and trying to set up a Facebook connected site. There seem to be three available options at the moment:
Use middleware with PyFacebook. I was able to get the django-facebookconnect app going fairly easily and mod it to suit my needs, but it is currently unclear whether PyFacebook even supports extended permissions / if PyFacebook is still even under development?
Do everything with javascript. Teebes' javascript only django-facebookconnect seems promising along with reviewing the updated facebook authentication guide
Roll my own Python code a la Facebook's example
Can anyone point me in the right direction here? I plan to have users authenticate only through Facebook connect and then maintain dummy Django user accounts for each on the backend.
Thanks!
I plan to have users authenticate only through Facebook connect and then maintain dummy Django user accounts for each on the backend.
Seems you want exactly what http://github.com/flashingpumpkin/django-socialregistration does