I know that direct access to a database via Javasript is not recommended, since the user would get the database login and thus the ability to manipulate the database.
But in my case, the user cannot see the client-side code, since it's a phonegap app.
Is there a way to do it? And it not, what is a good way to do with a serverside part?
its really not recommened to access database from client-side its not only for security reasons, but what if you changed the database access or upgrade to different database, so you will have to change it in your app which you may not be able to access again after users installed if its mobile app and then you stuck to your database for ever,
so whatever you want to do you can add an action in server-side and depend on your params it will formulate your Query,
for example sending parameter for user=true this will search for users tables, sending parameter for account=true will search in users-accounts tables and so on.
Related
I've made a simple webapp that is going to show some data in a table, which will be updated weekly.
This update it done in the backend with some python code, that scrapes and alters some data, before putting it in a SQLite database.
After doing some reading I learned that to deliver that data to my webapp I should make a API with Flask, that can take that data and deliver it to the JS in my webapp in form of JSON, which then can use the data to populate the table. However, I should secure my API with username and pw. But as its a JS frontend that will retrieve data from the API, there is really no point, as the username and pw will have to be hardcoded into JS, which then can be read by the users. (I think)
Should I expose my API to everyone, or is this not the way to go to be able to use SQLite data as a backend for my webapp? I am fine keeping the API to a GET only.
You are correct, it is pointless for you to secure your API. Securing an API is only needed in certain circumstances.
If you are accessing data that you don't want anybody to see, perhaps through a backend call, then it would make sense to add in some form of security (normally an API key or Authorisation tokens in your request headers).
However, if you are making calls from your front-end (i.e. client side) to a backend API, then there is no point putting additional security there as the user can already see the request and already has access to the data the API is returning - so by securing it you are achieving nothing.
Normally, if the page the user is visiting contains sensitive data that you don't want everyone to see, you would take steps to secure your website instead (for example protecting it with a login for username and password before you can access that page). If you were to take this approach, where the website is protected by username and password, then you can update the API to make sure it does not respond to requests where the user is not authenticated (e.g. by generating a session token or something unique for each logged in user).
If you have a look around on websites that have lots of free data available, you will find they all have front end API calls that are completely unsecured (because it is pointless if the data is already free to access). Some websites do take steps to try to make sure it is their own website that is calling the API, but even then it is a bit pointless as web scrapers can always extract the data from the HTML.
Take a look at this page which outlines authentication headers. This simpler route is to hard code the header info in Flask to make it a little more secure. You could also try the more involved route of reading header info from your db. What's currently working for me to read from postgres db is below so you may modify it slightly for sqlite.
def valid():
headers = request.headers
auth = headers.get("X-Api-Key")
user = User.query.filter_by(apikey=auth).first_or_404()
print('from search of db ',user,'',auth)
return str(user)
As you mentioned, you plan to show a public data - then it can be used even
without authentication. Otherwise I think it can take too much unnecessary time spent on that.
As you have just a simple and single table from database, I believe that you don't need an API. You can just create HTML template and render it with data. Some examples can be found here and few more here.
The situation is that I have a website, where at the end the user can order with filling a form, but no registration or log in is required, to be more specific, there's no possibility to register or log in. When the form is filled, with the submit button I want to validate the input with a function, and if they are valid, send it to Firebase. There are a few problems:
there's no possibility to authenticate the user, I need to set the Firebase security rules as "open", so everybody can write and read data to the database (but it may be a good solution to set as everybody can write, but just I can read data.
I read a bit about the config variable, and there's no good possibiity to hide that, so if somebody write a simple js program, and set the config as it's in my file, it can do whatever it want with the database
I was thought about that is it really the best solution to read the users input as order, I was thought about that maybe js can somehow send me the data to my e-mail address, but after careful research, I can't found a possibility to that. Anyways, it's sure that there's a solution to the Firebase problem. What I want is to set the only possibility to write to the database through the website, and read the data just through the Firebase Console.
There's not much you can do if you aren't authenticating your users, I guess the best option would be to set up write rules to protect the integrity of the data being saved (so even if someone with access wrote to it they'd have to follow a structure): https://firebase.google.com/docs/database/security/securing-data and set read rules to nobody.
Another method may be to have an API on a backend server which makes sure all requests are coming from your website only before saving it to firebase. This way you won't have to expose your firebase config.
In addition to #AlchemistShahed's answer, I'd recommend checking out Firebase's anonymous authentication. This gives each user an ID, without requiring them to specify any information. It's pretty much a persistent session ID, with as little code as:
firebase.auth().signInAnonymously()
By embedding this (anonymous) user's UID into the data they write to the database, you can easily detect when a single user is flooding your queue with data.
You could write a cloud function that would be called on form post, that function would check and sanitize data before inserting data into Firebase. Since data insertion would be done from the server side, no config would be present client side. Then set security on Firebase so only you can read.
You can also check those links, you might find something else in there.
Here's a link to some common use case for Firebase rules:
https://gist.github.com/codediodeio/6dbce1305b9556c2136492522e2100f6
Here's a link to Firebase security doc: https://firebase.google.com/docs/database/security/
I have already found many answers about this like link
But I don't think it really solves my problem,
I still can easily get my database instance in client side:
firebase.initilizeApp(config);
db = firebase.firestore();//db can be considered as an instance
Then simply type code in Chrome console:
db.collection("abc").where("id","===","1").get().then(function(){//do something})
to get my data.
However I still want the client side is able to do CRUD but only through the page events like click or drag or something else.
So in such situation, is it possible to achieve it?
When you add a website to your firebase project where you would like to access the database, you're defining which URL cann access the database...
Checking authentication and integrity needs to be managed by the database rules though.
Therefore, once you've connected to the app and can fetch data, you can of course also do CRUD operations and create/read/update/delete data in there...
If you want to, you can of course also utilize Firebase functions as a bridge between website and database... there you could define REST-Calls that write or read from the database. However, you need to make sure to add authentication stuff there as well to prevent unallowed access.
I need to understand and maybe ideas about single page apps.
I want to create a project, i'll do it with MVC. I also want to use AngularJS for client side programming.
I know that AngularJS is good for single page applications and when working with SPAs you send your data to API to process. But data sent from Angular is visible to user and open to be manipulated.
I don't want users to be able to see any data or access to the API from the internet. Witch way i should follow?
I'm thinking about keeping sensitive user data in MVC controller. For example let's say user Id is very sensitive for my project. If i keep user id in javascript variable, when i'm sending it to API with some command user will able to change the id and manipulate the system. But if i keep user-id in MVC controller, via user authentication, and send request to my MVC controller then the user won't be able to change it. But i know this is not the best way of doing things, there must be a more clever way.
I'll be glad if someone can explain how this things works in SPAs or when you use Angular and MVC together.
This won't work, you can't prevent user from tampering the data, crafting custom request and doing whatever she wants at her side.
What you should do is to never trust upcoming data - which means validate every incoming id twice, once when you produce it and then when it comes back. Either it comes plain and you verify if it's legal or you encrypt it so when it comes back you decrypt it.
Some data can be stored at the server side, the id you mention is such example. This way user never sees the data, what you pass is the session id which is a long random value, rather impossible to craft. This approach comes with the cost of server side resources that are used, the more users the more resources at the server stored between requests.
I just want to know can I create registration page with using javascript in html page and store all details to the client-side cookie session or I should have a database to store all information there?
Any help would be appreciated
This has to be server side, in a database. Why would you want to store this on users computers? What would happen if they moved to a different computer or deleted their temporary internet files? You'd cause problems.
Hi there, I just want to know can I create registration page with using javascript in html page and store all details to the client-side cookie session
You could, but then the user would be registering with their browser rather then with your website, which doesn't appear to make sense.
should have a database to store all information there?
Having a server side system which stores information in a database is the standard approach.
If you want to persist your user information and if you want your user be able to login to your application from anywhere, then you should use a server side database and store your registration information.
Yes, you could do that, but it would not provide any kind of security. It would also mean that you lose out on the ability to keep track of your users, unless the cookie is read by the server. Finally, your user's registration would only be valid on their computer, again unless there is a way for them to retrieve their information from the server (which means the server will need to have it).
If it's a HTML5 app you could use the localStorage and sessionStorage Objects to store your info however if the items you are collecting are security sensitive I'd send the info to a database or a protected file on the server. Leaving sensitive info in a cookie isn't wise.
If you're working with passwords, get that stuff into a database and encrypted/salted!