We are going to build Mobile apps to access the data inside of firewall for our employees to use. We have the skill to build hybrid apps. We are looking for a solution to be able to authenticate users to use the apps. Below is the ideal solution.
Can we upload our apps to a private app store to allow only our employee to download for both iOS and Android users?
How to access the database inside the intranet?
How do we authenticate our users? (use Single Sign On) either authenticated by our mobile app or 3rd party software. (like GOOD)
Does anyone here know any platform or product we can use? Any suggestions? Thank you very much.
I would also like to know the options for question #1.
As far as authentication and access to intranet data....
Something will have to be exposed to the internet that will allow access to your data. This can be accomplished by writing a node express server that acts as a proxy to your data. The node server can also handle the authentication before serving up the data using jwt (JSON Web Tokens). You can find and example here:
https://scotch.io/tutorials/authenticate-a-node-js-api-with-json-web-tokens
Related
I have been searching for a proper answer to this question, have a bit of background in front end development, but with new concepts like SaaS, PaaS, etc. want to get information from experts out there, that could help any newbie to understand what it's all about.
Say I am trying to develop eBay like an app that takes a product from a user and sells it back to the other user who needs it.
Will my app need a backend server? If so why? I am already uploading my app to Google Play Store or Apple Store.
How will the backend server like HEROKU or FIREBASE or AWS help my app?
Can I implement two different services in single app, say for eg., firebase for backend database and HEROKU for payment processing?
Thanks again for your time and information.
SaaS
Answer: SaaS stands for "Software as a Service". In layman's terms, someone developed some software and hosted it somewhere. You can use that hosted software in your software project/product as a third party service (like public API); or directly use that as individual software under some license like Firebase as mentioned.
PaaS
Answer PaaS stands for "Platform as a Service". In layman's terms, someone configured some hardware and exposed the hardware controls via some web based application or REST APIs. You can use that hardware to deploy/run/manage your application without having the actual hardware on premises.
Backend Server
Answer First of all, let me explain the server. The server is a middle-man who serves whatever is requested of it, and all browsers/mobile apps act as client. So for example, the web is all about client-server communication.
So taking the example you mentioned, an eBay-like app takes a product from a user (client action) and puts it on the server (client requests in background for server to put product on server). Then another user opens the app (client action) and searches for the product (mobile client requests server to return that product, if valid and matching search criteria), and then he can buy it (mobile client will request server to complete the purchase).
You have to understand that for any communication between web application, mobile application or desktop application, there will always be a server. Even in file sharing applications like shareit, one mobile app works as server and same mobile app elsewhere works as client.
Yes, backend servers like Heroku or Firebase or AWS will help your app to complete your application business flow.
Yes, you can implement two different services in single app, say for example, Firebase for backend database and Heroku for payment processing or hosting your application/APIs.
Unless you are experienced with building distributed applications that can persist data across multiple nodes in a consistent manner, and ensure data available, I'd say you most definitely need some kind of backend. Unless of course you only plan to have user-to-user transactions, that can rely on direct messaging between client applications - which seems pretty pointless and quite far from the requirements of an EBAY-like product.
In terms of the architecture, you can follow many different approaches, but in most of them you will require some sort of data access layer. I'd recommend looking into the three-tier software design pattern (https://en.wikipedia.org/wiki/Multitier_architecture) to better understand the way this type of software product is typically designed.
After sorting out which type of data persistence you prefer, you'll need to setup the backend where your mobile app will connect to retrieve the data from (things like products being sold, user profiles and ratings, your own history). Of course you could also connect directly to the database from the app, but that would be a big mistake - it would meaning making the DB access publicly available, and thus exposed to attack, not to mention that you would be hard-pressed to find a solution for user registration and authentication, which would have to be provided by other means anyway. Typically your backend will also manage user registration and authorisation.
Heroku, Firebase and AWS are all very different, each with their strengths and weaknesses, but there's nothing like trying them out to see what fits best. What you refer to as "Google Server" and "Apple Server" sounds like a misconception, and you probably mean the Google Play Store and the Apple Store. These are not applicational servers that you can use as a backend, and serve only as a repository for your mobile app from where users can download it, and nothing else.
Without some sort of backend mechanism, the challenge of making data available for the consumption of multiple users would be overwhelming.
I know this isn't a very specific answer, but your question is quite broad-reaching, and it seems you need to look into some basic fundaments of software engineering before going into more detail.
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.
Friends I'm Planning to design an application such a way that user has to login and he has to enter the data to be stored in cloud and if he opens the account the data should be edited other wise it should display the data.
I would look into solutions such as couchbase:
Apache CouchDB on Android provides a simple way to sync your application data across devices and provide cloud backup of user data. Unlike other cloud solutions, the data is hosted on the device by Couchbase Mobile, so even when the network is down or slow (airplane, subway, backyard) the application is responsive to users.
What this means for you:
You can embed the rock solid distributed database, Mobile Couchbase,
on your Android device. Your Android apps can use Apache CouchDB's
well-proven synchronization technology. If you <3 CouchApps, you can
deploy them as Android apps.
check it out here
I'm planning to develop an Android application with an app-engine backend.
However I would like to refrain from using authentication (either with Google accounts or Open ID). Since the data will be sent only from my app and not any other client, and will be over SSL connection, I consider the data safe and trusted.
So my question is two-fold:
Is there any security issue I'm missing here ?
All the examples I found use some sort of authentication. Is it at all possible to use the android appengine infrastructure (RequestFactory, etc) without authenitcation ?
An app engine application is just a regular web application deployed on app engine. If you need to authenticate your users, do so. If you don't need to, then don't.
You're missing something, though: once a web app is deployed on app engine, it's accessible from anywhere on the web, and so anyone (and not just your app) could send requests to this application, whether you use SSL or not. SSL will just make the communication encrypted, and ensure the client that they're talking to your web app, and not to a rogue web app maskerading as yours.
I have been asked to write a mobile android app to interface with a website. When pulling content from the site, I don't think scraping the site would be very efficient. I would like to interface with the database. Think of the scenario as facebook mobile app interfacing with the facebook databases that fuel facebook.com (so there's a mobile app, a web app, and a database in this equation). Would I just create a db account for the mobile app and then every phone using that app would use the same database account (This sounds like a terrible idea imo)? The user will be asked to authenticate in the app before they can start getting information from the it.
In general you don't want to be accessing the database directly via the phone (if that is even possible). The more standard way with mobile clients is to build a set of RESTful APIs that you can invoke via normal HTTP GETs and POSTs. These will present the data in a more lightweight (JSON, XML) way to the app, so that the "decoding" effort is reduced. Authentication is done via standard HTTP AUTH. That's the short version.