We are making android application, which needs to get data from mongodb database. There will be many entries in database and there will be requests quite frequently. Should we access it directly or make a PHP script, which would access it and return required results in JSON?
Should we access it directly
You definitely do not want to expose your MongoDB server(s) to the Android application directly, especially if the application will have a user role allowing write access to the database. Anyone with access to the Android app could potentially discover and extract those credentials, and if your Android app is designed to connect from a wider network this exposes your MongoDB server unnecessarily. You may also be opening your MongoDB server to possible denial-of-service attacks or rogue queries.
The MongoDB documentation has a detailed section on Security Concepts including network exposure and security. Best practice for any database deployment is to limit the range of network addresses that can connect directly. Generally direct connections should be limited to your application servers and monitoring apps, which are probably hosted within the same network infrastructure.
make a PHP script, which would access it and return required results in JSON?
Yes, a recommended approach would be to write your own interface which provides a suitable API and authentication controls. You should be able to find a PHP framework and/or libraries to minimise the amount of custom code you have to write (eg. REST, JSON, Oauth).
The interface you implement can:
put some constraints on the type of queries that end users can run (only what you provide, rather than the full MongoDB API)
allow the application to authenticate with appropriate user privileges without having the database credentials embedded in the Android app
add additional user security such as token-based OAuth or Twitter/Facebook authentication
abstract the endpoint that the Android app connects to (your web interface) from the infrastructure detail of your MongoDB deployment
potentially include caching for common queries or session data
I would pick the option of creating the PHP script that will handle all the logic and data filteration, send back as JSON response to be ready for the application.
as marked in bold, that will allow you not to worry about filter the data in your client "android application" side, and leave all the dirty work to be done on the server side.
There is a two options
Make an API service that will contains all CRUD operations so you
will be able to call from you application.
You are able to access directly via Java MongoDb Driver. Read
more here how to get start with java mongodb driver.
Related
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)
Background
I have a EC2 instance with a RDS instance(MYSQL) associated with it.
I want to use a android app to execute queries on that MYSQL instance.The Android sdk of amazon does not support RDS.
Problem
How do I connect my android app with RDS instance?Is it possible to use RDS(MYSQL) with an android application without sdk support?
RDS is not a database engine. It's a service that manages the infrastructure for you that's required to maintain a highly available and fault tolerant database. It supports a number of different engines such as MySQL as you mentioned. Please read the docs for more information.
You need to connect to your RDS MySQL instance the same way you would connect to any MySQL database. Using a library that supports MySQL, and using the hostname, username and password for your database.
However, it's probably not the best design to have phone clients connecting to your database remotely. The best thing to do would be to put a REST API on AWS that interfaces with your database.
Having n users connected to your database from each handset using your app is probably a bad idea. It means you need to have more power in your database, greatly hinders your scalability and makes things less secure as the database is exposed to the internet. With an API in front of it, you can build a much more fault tolerant, scalable and solution.
The "cloud way" to build mobile apps is to (within reason) build your application logic on the cloud and simply have your client code connect to your API. This way you can spread to more platforms (eg. IOS, Web) much more easily as you won't have to manage separate application level code for each platform. You'll just need to manage code that integrates with your already existing API.
Take a look at this whitepaper. Ignore the web server tier and focus on the App Server and Database tiers. This is probably the best design to go by.
I'm building my first app which uses an external database for storing data..
And I'm struggling with the following question:
How to connect with my database: use the Amazon DynamoDB sdk for Android or create a restful api based on NodeJS on my own server, which passes the data to DynamoDB?
I'm very new to this and when I look over the internet I see amazon suggesting to use the SDK.
The only problem is, if I want to change the data structure in the feature, what kind of problems will my users experience with the current versions of the app? And is it safe to save my Amazon keys inside the app (cause people may be able to decompile the app)?
On the other hand, I do have to pay for the extra server which handles the connections between my app and DynamoDB. So... is it worth it?
So I'm quite struggling with this.... What do you guys think?
I would go for direct access from your mobile application to DynamoDB.
This would allow you to scale your application much easier : you do not need to maintain, operate, secure a middle layer, AWS does that for you. You will also save on the cost of running your couple of NodeJS servers, load balancers etc ...
You should not store access keys / secret keys in your application but rather use AWS Cognito Identity service to dynamically receive access keys and secret keys for your user session. These keys will be limited in scope to whatever permission you define for your Cognito users and limited in time (default is 15 min)
Cognito works with backend identity providers to authenticate your users (Facebook, Google, Amazon, openID connect or your own backend) and can also work with unauthenticated users.
More about Cognito : http://aws.amazon.com/cognito/
More about Cognito ID for Android Mobile Applications :http://docs.aws.amazon.com/mobile/sdkforandroid/developerguide/cognito-auth.html
I'm not sure that the accepted answer is complete because it does not acknowledge use cases, and it does not address the question asked of "what if I want to change the data structure." Well, if you have outdated clients, and change the data structure of the documents in your nosql database, then those clients will not be able to access it. I don't believe DynamoDB offers a middleware platform to support this kind of old-to-new model adaptation. You'll have to force an update to your clients.
In fact, there are many operations beyond user-based permissions (which Cognito does do well) like this that you might need middleware for. Perhaps you want sorting logic to occur at request-time, and not maintain a copy of that sorting logic in every client application.
The question of "is it worth it" probably depends on the complexity of your application and your users' relationship with the data (ie. if the presentation layer basically just wrapped data -- then directly access DynamoDB. If you your presentation layer is not just wrapped data, then you should probably use custom middleware). In truth, I stumbled upon this question while running my own cost-benefit analysis, and am not sure which approach I will take. Another major factor of mine is that I might choose to switch database solutions in the future.. this will be more challenging to update on every client, if my clients are directly accessing the DB.
The one certain conclusion I've reached is that you should use middleware somewhere in your system, such that you can decouple your database vendor from either the client logic or the server logic as much as possible, eg. in a mobile app:
writeToDatabase(Data data){writeToDynamo(data);}
To achieve this, AWS suggests using Amazon Api Gateway as a proxy for AWS services, and even has premade configurations for Amazon API Gateway to behave as AWS service proxy.
I'm new to Android, but I'm ultimately hoping to create a social networking app. I'm trying to figure out the best way to store user data (profile field responses, etc). I'm planning to use Google App Engine for data storage. Very generally, how do I take data gathered from, for example, an "Edit Profile" page and (a) store it in the GAE datastore and (b) make it show on the user's profile? For example, what methods would I use, and how would I set up user data? Also, I know there are more user-friendly interfaces for GAE datastore like Objectify and Slim3; can these be used with Android? I apologize if these are general questions, but it would be great if you could point me in the right direction!
GAE is a Server side platform while Android is a client side platform. Both of them while using Java as their base language have different SDKs. So you cannot mix them.
The approach that you will need to take is the following:
Build a simple REST Web Services layer for your Server side application that is hosted on GAE.
The Android client will make a REST call to send and get data from the Server.
On the Server side Java application that you host in App Engine, you can use the Datastore API. If you want to be a bit more productive you can look at libraries like Objectify.
On Android, I suggest that if you are going to store preferences/profile details for the user, you should use the following:
a) Use Android Preferences. This will save the preferences data on the device itself and will not need network calls to happen between the device and server just for the sake of getting preferences.
b) Any data that you really need to save on the Server, you should as mentioned earlier make a REST Web Server in GAE and invoke it via HTTP Networking on Android.
Hope this helps.
I am in the process of developing an app with the help of someone else for a site I am developing. This app being developed will require access to the database on the web server. So my question here is typically I would want to keep my servers access limited to specific IP's however. Mobile devices all have there own ip's from what I hear. So if this is the case I essentially have to open up my database access to allow any inbound remote connection. Which is more than possible, but I forsee a potential security risk with that. namely in the notion of someone attempting to brute force the DB to gain root access or something to the effect there of. With that my question comes down to is there a more secure way of doing what I need in the overall? Is there any methods I can apply that would allow me a little more peace of mind. The DB I am currently using is mySQL, and will generally remain that type til later in the future.
Your concerns about security risks are valid. You should avoid a situation where countless mobile apps are making database connections to your MySQL database. A better solution would be to host a REST API layer in front of the database. This would allow you to control what portions of your database are accessed, but potentially include authentication routines as well. The REST web services you publish will give you the opportunity to produce permitted representations of your data rather than raw access to the data. That means in addition to producing web services, you'll need to develop the app to be a REST client that consumes these services or makes "requests" to them on an as needed basis. Obviously, this requires planning on both sides of development (back-end and front-end).
One possible solution to consider for producing REST web services is here:
http://phprestsql.sourceforge.net/
There are additional frameworks available for PHP, Java, ASP.NET and other platforms.
http://peej.github.com/tonic/
http://jersey.java.net/
Good luck!
Why not access the database via an API and then secure the API? So in essence, you should have a REST(or anything) API on your web server which your mobile application talks to which subsequently talks to the database. Accessing and securing your API will make a more cleaner and leaner design.