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.
Related
I am developing a voting application based on Android. This app will be used to create user accounts, receive notifications and caste vote.
I want to develop a back-end server for this application which will also have an Administrator interface to create new voting events. I want to know what all options I have to implement this project.
The server must maintain user account records in a secure manner, send out one-time-passwords from email, have sessions implemented for users logging in from the Android App, send out notifications about upcoming events to the app.
What back-end technology, database, parsing(for communication between server and android application), encryption(for secure communication) should I use to make this possible?
I also want to know how would I be able to host this server, both on a local virtual machine as well as on an online hosting.
The scope of your project is far too large if you're wanting sessions, administration views, E-mail integration, encryption, etc., without even knowing how it would all interact, or even what language to use.
As for what languages / services you would need, it varies for each task:
For administration views, you're probably looking at either ASP.NET or PHP with a CMS.
In terms of security, you'd want either MySQLi, or preferably, PDO. Make sure to read up on how to prevent things like LFI, RFI, SQLi, and XSS if you want semi-decent security.
Both ASP.NET and PHP can handle sessions, and they're fairly easy to understand in either language, so that wouldn't be too much of a concern.
While you can send out E-mails directly using scripts like PHP's mail() function, you probably want a system that can easily monitor things like how often users click on certain links, where the people who click the links are located, what campaigns are most effective, etc. For that, you'd want a service like MailChimp, Marketo, or Pardot.
As for how to have the back-end interact with the front-end, you're working with Android, so you're probably working with Java. That means you would be limited to functions like HttpMethod. Having said that, you can create plain HTML applications, or use a service like PhoneGap. In either of those situations, you have AJAX at your disposal, which will make things a lot easier.
For hosting, simply do a Google search for 'web hosting service'. There's literally thousands of decent hosts. Some have better pricing than others, but some have better features. I can't really recommend any brilliant ones, as they all meet different needs. To host locally, you'll want either IIS, or WAMP / LAMP depending on whether you are running Windows or Linux.
If you're not familiar with almost every term that I've mentioned, then the scope of your project is too large, and you'll definitely want to scale back.
I don't mean to scare you off, just making sure you're aware of just how difficult it would be to put all of that together :)
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 am new to Android and taking the risk of doing a final year project of building an Android app. I would like to know whether I can create Client-server architecture application in Android. I'd like the front end to be the mobile app. Also, where do you store data (I don't know where to store data exactly) at back end.
Use Restful web Services with json(Ex: WCF in the backend with Sql Server)
For Mobile App, These are useful tutorials http://developer.android.com/training/index.html,
http://www.vogella.com/tutorials/android.html.
Very many, if not most, existing Android apps retrieve data over the Internet and display it (e.g. the StackExchange, Yelp, or Facebook apps). They are clients requesting data from servers and therefore fit into the definition of being “client/server”. I'm hard-pressed to think of an app on my phone that isn't a client to some kind of web service.
If, as your question suggests, you are using HTTP for client/server communication, there is no reason why the client platform (Android) should have any impact whatsoever on the server-side implementation. In the wild, Android clients are served by servers implemented with every conceivable combination of OS, language, and database. Therefore “where do you store data?” is an unanswerable question, as the answer depends entirely on implementation choices that you make on the server side.
I am trying to develop a system that involves a:
server with a database that will handle the system's logic and manipulate data
an android app that will interact with that server (pull and push data into the server)
a website that will do the same as the android app, but from a website with slightly different data.
What I thought of is to use SQLite with Apache Tomcat installed on the server and deploy a Grails war file on it. That will take care of the 'website' side of the system. But what about the android app? Can it communicate with Tomcat as well?
Tomcat will suit your needs. I would look at hosting options though. Are you hosting your own server, or do you have a hosting provider? Do you have experience hosting a tomcat server etc. Do you have experience with java web applications, or other web frameworks? All of the above, and probably more should lead you to your decision on what type of framework/language to use on the server. This in turn will lead you to your options for hosting, and web-container to use.
Once that is determined all major web frameworks will allow you to publish web-services Rest, Soap, etc. that can be consumed by an android application.
Also, if you are planning on providing a web interface and service at the server level, my guess is you are going to be storing a fair amount of data, I would look into a more robust and scalable database such as mysql or postgres. This post contains some insights into this.
If you have an API that is web accessible, an Android can access it.
Android shouldn't have any problems communicating with Tomcat.
Look at http://grails.org/doc/latest/guide/13.%20Web%20Services.html for more information.
A RESTful web service is most likely what you'll need. Android can consume SOAP web services but it requires more work for less overall functionality.
I have an Android game and I want it to store data - say a high score for example - against each user on a server backend.
Here's a list of outrageously demanding requirements! It's unlikely any solution can meet all these demands, so I've changed/prioritised them:
Minimum/very easy server and client code
Free/cheap
Automatically scalable and no/little server maintenance
As secure as possible with minimum code
Seamless - no user action required to authorise/choose anything
I know about Parse, and that seems the easiest option but I'm concerned about the future cost and would prefer more control so I'd like some alternatives.
AWS seems a lot of effort, although it handles secure anonymous authentication fairly easily and well.
App Engine would be great if there was an easy way to secure requests without requiring the user to login or authorise app engine.
So... I want the seamlessness of Parse, the security of AWS, and the auto-scaling of App Engine. Also the ease of use/coding of Parse. Fingers Crossed. :)
Thanks
My advice: use Parse, but create enough abstraction/encapsulation in your models so that swapping Parse out for another service won't be so painful. But seriously, I don't think Parse will get expensive (or even not-free) until your app is seeing very high demand. Furthermore, the Parse guys seems pretty committed to openness: you can export your data as a CSV and they have a REST API so any type of program you write can access the data.
If you're determined to roll your own, I'd recommend creating a Rails back-end with Heroku. Piggyback SSL is free, HTTP Basic Auth is really easy in Rails, and the entire stack will play nicely with whatever db you'd want to use (I'm assuming NoSQL since you want flexibility).
Any PaaS that supports SSL and a dataabse will probably do. Estimate your traffic, data storage and processing needs and pick one that is cheap enough to get started. App Engine is going out of beta soon, and the pricing model will be changed, so if you want autoscaling you'll have to pay for it.
What exactly is 'secure anonymous authentication' and how does AWS support it?