I have a .csv that I want to use as a database and run SQL queries on it from the browser. (Ideally I want to upload the .csv, first. But It could also be stored). Thought this could be done with Django and a Postgres database. Are there simpler ways of accomplishing this?
Is WebSQL an option? Is there something else, I haven't thought of?
Ideally I would want to avoid SQL injections. I tried searching on stack overflow and found this (Display SQL query results in php), but it's not what I'm looking for.
Basically the desired functionality is: when one comes to webpage, they can run SQL queries on the data in the .csv. They type queries in an HTML form and submit the form and then the results would be shown on the same page with actual query.
Use an in-browser library to load the data from the csv file, for example Papa Parse, then equally using an in-browser library, but this time for SQLite, create an empty in-memory database, populate it with the loaded data from the csv file, and then query the database with the same library.
It appears that you are asking if you trigger/run SQL queries against some SQL database directly from a UI. While this is theoretically possible, in practice it is a very bad idea. The reason it is a bad idea is that to do so you would have to open one or more database ports to the outside. This in turn would expose the database to DOS (denial of service) and other types of malicious attacks.
The proper way to proceed would be to place your database behind the backend of your web application. Then, expose one or more endpoints in your backend which in turn talk privately to the database. Finally, allow your UI to hit the backend endpoints to run whatever SQL logic you want.
Related
I'm trying to create a simple in-browser web app to display the contents on a given rethink table with some nice formatting. I'm having trouble finding a way to actually connect to rethink without having to use node.js. All I want to do is get the data out and then run it through some styling/layout stuff. Node + dependencies are overkill for a tiny browser-only app.
Unfortunately, you're going to need a server. It might be node.js or it might be another language, but you'll need a server.
RethinkDB is not Firebase. It can't be queried from your browser. If you absolutely need browser side querying and can't have a server, you should use Firbase.
If you want to use RethinkDB, you can just have a very thin server that just redirects your queries to RethinkDB. This can be done over HTTP or over WebSockets.
Why
Ultimately, the reason why you don't want to query your database from the browser is security. RethinkDB has no users or read only accounts. That means that if your database is accessible from your browsers, anyone can come and delete all your databases (including your system tables) with a simple query.
For example:
r.db('rethinkdb').tableList().forEach(function (tableName) {
return r.db('rethinkdb').tableDrop(tableName);
});
And now, all your database is gone :).
Keep in mind that this is something the RethinkDB team is aware of and working on.
https://github.com/rethinkdb/rethinkdb/issues/218
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.
I have an excel sheet, a JS application and a db. excel sheet has data. I need to open the file and read data from the JS application and insert it into the db(say oracle db). How to?
I think we cannot open and close file in JS, pls correct me if i am wrong since it poses a security issue. If that is the case, say if we have updated the data in the grid, or table in the JS application. and we want to insert all the data in to the db, how do we do it?
First- there is pretty good module to read/write excel files in javascript-client or javascript-server:
js-xlsx
Someone has used it and provided a blog on its usage here
Second- You have to involve one more tier (server) to get the work done as per security standards. Or another option is BaaS (Back-end-as-Service) like Parse, Firebase to serve your client as database, it lets you directly save your stuff without involving/writing server. Or other option is to use SaaS like Mongolab, it exposes api for client to directly save into db.
Happy Helping!
You cannot do this safely. You need a webservice that the javascript app can call and that service would write to the database. So you should build a restful web api.
You need a Proxy Service for interacting to DB. There is no db-connectors for JS. The simplest way to achieve your goal is to choose one of the scripting languages which can run on your server. Such as PHP, Python, ASP.NET, ASP etc. I suggest PHP or Python.
I have a local website running that will query a mysql database via inputs given by a html form. The form values are sent to php via jQuery to call the query. Is there a way to send a command to the mysql server to kill the query if the website is refresh?
Currently if I refresh, the last mysql call will still run, so the website will be locked up until that query is finished.
Edit: To give a little more background information on the website, it is a local website that is solely running d3 visualizations based on a series of involved queries (lots of full text searches) on a large database (3 tables all in the 1 - 5 million record range). The "lockout" I'm referring to is not being able to abandon a query and try a more efficient query (i.e. something that will limit my results more).
Perhaps there is (it generally involves selecting the last process ID from the MySQL Processlist and issuing KILL QUERY on that process ID), but there are some problems that I think you should try to address first.
To begin, why in the world does one query "lock up" a website? I might be smelling a design flaw.
JavaScript could be used to make the browser "hit" the server on a refresh, but that's just adding another AJAX call and, presumably, another MySQL query (having to do with the processlist) and more PHP to write to handle the AJAX call, the processlist lookup, and the KILL QUERY query ...
I would recommend you try and make the server/MySQL query more efficient, so that you don't have to get a flying flip whether the browser is refreshed or not. As for browser security, you could probably use either PHP or JavaScript to enforce some sort of "flood limit" on repeated refreshing ....
I have a small database with some basic user data in it (uid, username, email, password, etc) which is used by various SQL queries and PHP so having a full table structure there makes sense.
However a new feature will add a few new tables where each user will "own" a number of rows in these tables (say 100KB of data for each user). However from the DB standpoint, all I really want to be able to do is either set all the data for one user, or get all the data for one user.
The data will then only ever be viewed and edited client side, using JavaScript. Of course the JavaScript can not directly run the SQL queries, and after the data is edited and submitted as a HTTP POST, trying to put together the correct set of UPDATE, INSERT and DELETE queries in PHP by tracking whatever changes were made by the user that session is somewhat complicated.
Instead what I am thinking is to just have a TEXT field in the database for each user, and store JSON or XML in it. The JavaScript can then just be given that to populate the HTML table and after the user is done editing that table the JavaScript just needs to collect all the data back from the HTML form and post it. The PHP then just needs to run an SQL query to overwrite the existing data.
While this seems the simplest way, it does seem to be a bit of a misuse of an SQL DB. I am also wondering if it is better if the initial before-edits table was generated by PHP in the first case, not the JS once the document has loaded?
Using a text field to store data for cases like yours is a common practice. However, if you decide to do that move, take into consideration the following issues:
Stick to a fixed format. If you store data as plain text, be aware that the database will no longer use its mechanisms to ensure data integrity and format unification. So if you have a few records with a given format, then change it and add a few more with the new format, those with the old format will no longer work, unless you ensure that you support both formats. So, your data format should be mature and consistent enough.
Estimate data length. You should have a good idea of how long the data text will become, in order to guarantee it will fit the database column you are storing it in. Some databases have issues with unlimited data type columns (like TEXT) so you should know your db server well, as well the deployment configuration. Usually MySQL and PostgreSQL will not have issues, but in my experience I have faced serious problems with Informix - so your database server matters.
Do not rely on client code. You mention to be creating the data via javascript. I recommend at least submitting the JSON to the server and producing another JSON from it to store in the database, or validate it in some other way. Otherwise, it may be possible for a hacker to add malicious content, or perform DB injection, or otherwise compromise your application if you do not take measure when free-form client data is added. If, however, the data is entirely generated on the server, the risks are fewer.
So, in general, this is not a bad practice in terms of database development, but as you see, provides additional considerations. If you figure them all out (I do not pretend to include all in my list, just the most common that I have personally faced), then you will be OK.