I see many people trying to connect an Android device directly in a database like SQL Server or MySql and the answers are always the same: Use a web service. Why not connect directly an Android device with a database? I'm using a local network with my Android application.
There are a number of reasons.
Security- If the user has direct access, they can get anything from your database. Plus they will have a password into your database. As a result, if the SQL server you are using has a flaw, then they can exploit it. Also, if your permissions are set up wrong, the could wipe your database.
Speed- If the users frequently use large queries, then it can bog down your system quickly and needlessly. If you go through a web interface, you can throttle it.
Accessibility- Web queries are supported by almost everything. It requires special clients to access SQL databases directly.
But if you trust your users completely, have the right libraries/drivers, then you could allow direct querying, and it might even be a bit quicker.
If your app connects directly to the database server you have to hardcode username / password which is very insecure. With some tools an attacker can decompile your apk and can access username / password in this way and can connect to your database with read (+write) access without using your app.
Another reason not to access database directly
Problem If you changed database architecture.
you have two solutions.
1- in direct access you will need to update every Client app
2- using service you only need to upgrading the service.
The reason is the connection
You're not sure how many time you'll have to maintain this connection, if it's stable and if you're not going to lost it
Secondly, web-service are optimized to retrieve an information and serve it beautifully with standarts. You can also cache the informations to spare your DB
Related
My application requires inserting data from the device into a SQL table. I have read that connecting directly to a database from an Android device via something like JDBC is usually a poor idea since if a user really wanted to, they could retrieve credentials from the APK, and in addition to this, the performance can be very slow at longer distances.
However, in my scenario no credentials are embedded in the APK; instead users will enter database & login details once a connection is required. Additionally, the only databases users will be connecting to reside on the same network the devices are connected to.
With this in mind, is it okay to implement a direct connection to the db or are there other security/performance issues I am unaware of?
So far I think it's a security thing that you're not allowed reading/writing to an Android SQLite database outside of the containing app's process.
But are there advanced techniques or tools that can be used to achieve this?
For instance, I want to make a web interface with a textbox where the Android app would connect to and then I can run SQL queries via said interface to read the database or to insert records into it.
I'm writing this question because I'm really stumped. Usually my search gives opposite results which is accessing a remote database with an Android app.
You will have to develop an API backend. The mobile app ( client ) will communicate with the API and do the desired operation based on the response.
It's not possible to directly connect to the app sqlite database. You can send web request and get the info you want, handle it in your app to store it in the sqlite database
You will have to add security measures, so everyone can't access your API.
So far I think it's a security thing that you're not allowed reading/writing to an Android SQLite database.
Apps can read and write to their SQLite databases. Otherwise, the database would not exist.
I want to make a web interface with a textbox where the Android app would connect to and then I can run SQL queries via said interface to read the database or to insert records into it.
You are certainly welcome to embed a Web server into your app. For example, Stetho does this to integrate with Chrome Dev Tools, offering your SQL interface among other things.
However:
Doing this for anything other than a debug build of your app is very risky, as securing a Web server is difficult enough when it is on a traditional server environment, let alone an Android device
The Web server is only accessible by whatever can reach the device via an IP address, which means it's usually only useful on WiFi (where it could be reached by other devices on the same WiFi LAN segment)
I came across a few tutorials online explaining how to connect to MySQL from an Android app, but they are a bit surface.
If I just write SQL and send/receive it in a POST, it seems problematic for a few reasons:
1) Hardcoding SQL with obvious issues there
2) Security concerns about sending sql - is that safe to send that request? or should it only be done via SSL?
3) To connect to the db, in order to insert things, I need to have the db connection info inside the app - is that safe? Can the code be read by someone hacking the device and the apps?
What is the best way to go about connecting and using a remote db from an Android app?
Thanks!!
Wrap everything in an API and manage authentication either with encryption with public/private keys or with a token-based system. You should never, ever, ever accept raw SQL in any way, shape or form from any device or site. Most often if you need live, remote data to run you should reconsider your application workflow and work off slightly stale data or provide the information in the background due to the possible spotty connections. Hitting even an API can be a costly endeavor so it shouldn't be something that has to occur frequently.
To incorporate some of the ideas above you could a couple things. For the public/private key read up on http://en.wikipedia.org/wiki/Public-key_cryptography. The basic concept is you store the public key on the device then negotiate a private key after the installation of the application that is also stored on the device (although not coded into the application). This key is the one you have to protect so it should be negotiated on installation and stored with the lifecycle of the application. You could contact an API with a unique hash of the device (say the device ID) and a password that the user could set. In that way if the data is wiped, since the password is stored on the server you can validate that a request to generate a new key is valid for that device ID and also protect against attackers trying to disrupt everyone's keys.
Obviously this is still susceptible to someone intercepting the initial request but if you are using HTTPS (which you should) then it should mitigate most of these issues.
You have to make sure an attacker just cant send in random device ID requests to generate new keys as it would disrupt the actual user's device of that hash, which is why the password set is important. Of course they could also do this against device IDs not currently registered but you could easily implement throttling and blacklisting against the initial API.
There are many things you can do but depending on your sensitive data it may be overkill. You'll have to make that judgement call and figure out who you are trying to protect your data from.
Use a webservice through which to communicate with the database. End User clients generally do not communicate with the database over the internet. Multitier_architecture
we are designing an application for android which has to store the details which the end users give ,into the database in the internet or cloud, where all the admins can access the same database for checking purpose through another application specially designed for checking with that common database. is it possible?
if so what is the database i have to use for?
where i have to host my database?
since there will be more number of users querying at the same time i cant use sqlLITE, so what else i hav to use?
guide me since am a noob in web apps development.
guide me since am a noob in web apps development.
Ahh - cos what you need is exactly a web app.
The web app has a DB in the background, and makes a number of URLs available that your android app can call over the network. These URLs read or write data to the DB. Since anyone could call those URLs you need to pay great attention to security.
As for what to write this in, it could be anything. PHP, Python/Django or whatever. For your DB, you probably don't want to use SQLite for the scalability problems you mention - instead MySQL or Postgresql maybe. There are literally thousands of hosts that might be suitable, depending on what language you use.
I'm building an Android application that needs to communicate with a MySQL database. The application isn't meant to be published, and I want the application to be the only thing allowed to interface with the web service I'll create for DB access.
I've been thinking how I can secure the system, and this is the idea I've come up with. I'd appreciate any feedback or other ideas. Surely there is a method built into Android that I am unaware of.
My thought is to give the web service a GUID. Each time a call is made to one of it's public methods, the web service matches its GUID with the GUID given to it by the Android application. If the GUIDs do not match, the web service refuses access. In short, my system has a 128-bit password.
If you trust the individual to administrative your database then everything should be fine. The most important change is that all of this communication must be done over HTTPS. If a hacker sees this traffic your database will get hacked.
I would still use a username/password combo to access the system. I recommend using the existing mysql.users table with the MySQL password() function. This GUID sounds identical to a cookie, and I would seriously consider using an existing session handling system such as php's session_start() instead of rolling your own. Re-inventing the wheal is bad, especially when it comes to security.