I have some concerns about using Firestore directly from mobile clients. I saw that with Firestore, mobile app is controls to db directly. There is only db side control is rules. However I am not yet understand how can I resolve my concerns. I worrying because with decompiling app or any other ways maybe someone can access maliciously.
To resolve my concerns and improve the security I want to:
Limit access per time for user. For example if some one writes or
reads db 30 second ago I want to block their access until 1 minute.
Especially it is important for writing.
I want to have the only document owner write their documents and
block others to write. For do this I don't want to store owner id in
same document because if I put this information to there, readers can
receive this information and maybe some way they can write request
with this information.
In summary, I want to prevent malicious and excessive requests exceeding limits. I want to avoid the risks in db side. How can I resolve my concerns in the two above matter?
Scenerio:
Think that there is harmful someone with name X. X knows how to
decompile mobile app or maybe knows how to request my application's
firebase Firestore account (maybe watched communication I don't know).
X wants to harm my application. First X watching communication and if
we give owner userid in document X receives needed information so
sending request with changing his/her userid or auth.uuid. Secondly X wants to
disable firebase of my application. For do this X sends too much
requests. The limit is overs due to too many requests. Note that: I am
using Firestore directly with mobile application. There is no web
service to communicate.
How can avoid this scenario?
Related
I am a rather fresh Flutter programmer so please excuse any flaws in the questions below…
I am struggling with a structural/ architecture dilemma. Here is the background:
App rationale:
my app allows its users to check little jobs available in their area and if they find time and are in a proper location to execute the job for a remuneration,
the app uses standard REST API (not Firebase) so that the server cannot be relied on sending status change notifications to trigger re-fetching of data,
the critical elements are (1) up-to date list of jobs for a given address - other user may have already taken on a job in an address (timed refresh of list e.g. every 5 mins), and (2) the app needs to keep track of the user’s location and accordingly ask the server for jobs if the user relocates by more than 2km in less than the refresh time,
The challenge:
I guess that on the basic level the app should have the following providers: (1) auth – providing the authToken, (2) geolocation – regularly checking user’s location, (3) jobList - for particular location (fetches high level job descriptions and addresses(, (4) jobDetails – fetches exact instructions for carrying a particular job,
as you can see: (2) geolocation and (3) jobList – need to refresh programmatically (at interval or on some change of geolocation), while (1) auth, (4) jobDetails are triggered by the user.
The Big Question ;) is … what is the proper architecture for the above type of app? More specifically:
should I use services for connecting to the server API and these would in turn be used by the providers?
how to ensure programmatic refetch of jobList on timer and relocation event from geolocation?
how to continually listen to location changes to detect a relocation but not overwhelming the app with processing?
should I store the (quickly outdating) jobLIst data just in its object class or should I use settings provider or a local db or maybe there is an easy way of storing the latest JSON response not to have to build the settings provider or db mapping?
in all my call to Auth api I need to provide the deviceId - how to make it available accross the app - this is pretty static but is needed in authentication so should checking it be a part of the auth provider?
If you could comment on the above or suggest a source of relevant examples I would be really grateful.
Thanks and cheers!
Here are my thoughts:
how to continually listen to location changes to detect a relocation but not overwhelming the app with processing?
You can rely on third party to do this for you. Such as: geolocator. With this, you can specify the amount of distance the user must have moved before the package notifies you of the change in user location.
should I store the (quickly outdating) jobLIst data just in its object class or ...
Since it is likely for a job listing app to use this data often and in various places, I would prefer to use db. It would be helpful in the long run too, if you plan to have some sort of analytics done on the mobile end or to gather any insights.
in all my call to Auth api I need to provide the deviceId - how to make it available accross the app ...
When you app is initialized, you could fetch the deviceID and store it in shared_preferences. Then in auth api, you could just retrieve it before making the API call.
should I use services for connecting to the server API and these would in turn be used by the providers?
As for geo location, geolocator can update you about the change in location and you could make an API call based on that.
However, if you plan to have a timer based approach to refresh your job listing, then you must realize that your users are likely to face issues arising from your inconsistent data. If you have plans to tackle it, then this implementation here might help. But I strongly feel that server supporting push notifications or maybe a web socket approach would be ideal here.
I need add multi-user capability to my single-page mobile app developed with Ionic 1, PouchDB and CouchDB. After reading many docs I am getting confused on what would be the best choice.
About my app:
it should be able to work offline, and then sync with the server when online (this why I am using PouchDB and CouchDB, working great so far)
it should let the user create an account with a username and password, which would then be stored within the app so that he does not have to log in again whenever he launches the app. This account will make sure his data are then synced on the server in a secure place so that other users cannot access it.
currently there is no need to have shared information between users
Based on what I have read I am considering the following:
on the server, have one database per user, storing his own data
on the server, have a master database, storing all the data of all users, plus the design docs. This makes it easy to change the design docs in a single place, and have them replicated on each user database (and then within the PouchDB database in the app). The synchronization of data, between the master and the user DBs, is done through a filter, so that only the docs belonging to one user (through some userId field) are replicated to this user's database only
use another module/plugin (SuperLogin? nolanlawson/pouchdb-authentication?) to manage the users from the app (user creation, login, logout, password reset, email notification for password lost, ...)
My questions:
do you think this architecture is appropriate, or do you have something better to recommend?
which software would you recommend for the users management? SuperLogin looks great but needs to run on a separate HTTP server, making the architecture more complex. Does it automatically create a new database for each new user (I don't think so)? Nolanlawson/pouchdb-authentication is client-only, but does it fit well with Ionic 1? Isn't there a LOT of things to develop around it, that come out of the box with SuperLogin? Do you have any other module in mind?
Many thanks in advance for your help!
This is an appropriate approach. The local PouchDBs will provide the data on the client side even if a client went offline. And the combination with a central CouchDB server is a great to keep data synchronized between server and clients.
You want to store the users credentials, so you will have to save this data somehow on your client side, which could be done in a separate PouchDB.
If you keep all your user data in a local PouchDB database and have one CouchDB database per user on the server, you can even omit the filter you mentioned, because the synchronization will only happen between this two user databases.
I recommend SuperLogin. Yes, you have to install NodeJS and some extra libraries (namely morgan, express, http, body-parser and cors), and you will have to open your server to at least one new port to provide this service. But SuperLogin is really powerful to manage user accounts and user databases on a CouchDB server.
For example, if a user registers, you just make a call to SuperLogin via http://server_address:port/auth/register, query the user name, password etc. and SuperLogin not only adds this new user to the user database, it also creates automatically a new database only for this user. Each user can have multiple databases (private or shared) and SuperLogin manages the access rights to all these databases. Moreover, SuperLogin can also send confirmation emails or resend forgotten passwords (an access token, respectively).
Sure, you will have to configure a lot (but, hey, at least you have all these options), and maybe you even have to write some additional API for functionality not covered by SuperLogin. But in general, SuperLogin saves a lot of pain regarding the development of a custom user management.
But if you are unsure about the server configuration, maybe a service such as Couchbase, Firebase etc. is a better solution. These services have also some user management capabilities, and you have to bother less with server security.
Given Firebase supports realtime push for web, android and iOS, I was tempted to try it out like pub/sub type push based system. Does anyone know if the firebase works and scale to large userbase? for example million+ users of chat conversations and users accessing that data simultaneously, what would be response time as users grow.
Firebase free and basic plans limit connections to 100. Their higher end plans limit connections to 10,000. That's done to prevent abuse.
From the Firebase website in case it was overlooked:
Those restrictions can be lifted though, and their Enterprise solutions can scale to millions of connections and terabytes of data
I cannot speak from personal experience with a million users but given the performance we have seen, it would be scalable to handle that.
Based on the scope of your project, I would engage them directly at support#firebase.com with your specific requirements.
One of our web site is a common "Announce for free your apartment".
Revenues are directly associated to number of public usage and announces
registered (argument of our marketing department).
On the other side, REST pushes to maintain a clear api when designing your
api (argument of our software department) which is a data stealing
invitation to any competitors. In this view, the web server becomes
almost an intelligent database.
We clearly identified our problem, but have no idea how to resolve these
contraints. Any tips would help?
Throttle the calls to the data rich elements by IP to say 1000 per day (or triple what a normal user would use)
If you expose data then it can be stolen. And think about search elements that return large datasets even if they are instigated by javascript or forms - I personally have written trawlers that circumvent these issues.
You may also think (if data is that important) about decrypting it in the client based on keys and authentication sent from the server (but this only raises the bar not the ability to steal.
Add captcha/re-captcha for users who are scanning too quickly or too much.
In short:
As always only expose the minimum API to do the job (attack surface minimisation)
Log and throttle
Force sign in(?). This at least MAY put off some scanners
Use capthca mechanism for users you think may be bots trawling your data
I'm currently working on an app sending request on a server for a voting system. The problem is that people can vote without registration but I don't want them to vote multiple time and I don't know how to secure this. I thought about a key system (generated in the app and verified on the server), but I'm not sure that this is the best solution.
What should I do ?
There are two possible solutions to this.
1) Handle the code that detects the duplicate vote on the server
For each vote cast the server stores the device id against the identifier of the vote. The server ignores any duplicate votes cast for that topic and sends back a "failure" response. This is handled by the device.
Pros: Centralized voting logic. Change it once on the server and all versions of apps in the wild conform.
Cons: You have to build the server logic. If you're more comfortable with ObjectiveC this may be an issue. You have to maintain the database of voting topics and devices that have voted.
2) Handle the code that detects the duplicate vote on the device
The device downloads a list of all the voting topics then filters them by the topics that have already been voted on. When a user votes on a topic then the device adds the id of that topic to the filter list.
Pros: No database maintenance beyond having a list of voting topics.
Cons: Users could remove the app, reinstall and vote again. If you want to change the voting logic (e.g. you want people to be able to vote twice on a topic) you have to update all the existing apps.
Admittedly putting the voting logic in the app makes the app more complex. However that added complexity has to be absorbed somewhere - either in the app or on the server.