Any help would be greatly appreciated!
My SDK Version is 37.0.1 and I’m building my app for IOS and Android.
So then the mobile app makes HTTP requests to the server. The server makes sure the requests are from valid users and that the user has the relevant permissions to e.g. delete the records they want to delete or whatever and then makes the request to the database on the user’s behalf. It will then return the results to the app (e.g. as some JSON data). When the app receives the response from the server it can update the UI as appropriate or notify the user that there was an error or whatever.
Thank you! That makes a lot of sense. One follow up question: what is the standard way for the server to make sure that the requests are from a valid user? Would I send a user’s username and password in the HTTP request to the server and it checks it against a database before proceeding with the request? Should this only be done with HTTPS? Or would sending the username and password in any form just be a bad idea?
There are a couple of ways to do this. Yes, one way is to POST the user’s username and password to the server. And you’re right that this should be done over HTTPS. The server should validate the username and password (Careful. Don’t store the passwords in the database as plain text. Otherwise if someone manages to hack your server they will have access to the users’ passwords that they have probably reused for Gmail etc. so the hacker might be able to use them to gain access to other accounts belonging to the user. Also, don’t just run them through MD5 either, because although that’s much better than storing them in the clear, it’s still often possible to get the original password back e.g. using a reverse hash lookup or via brute forcing the hash. You need to “salt” the password hashes. Basically you should not implement this from scratch yourself unless you know what you’re doing. You should use whatever your framework provides for authenticating users. e.g. Rails has Devise and Omniauth for this sort of thing.)
After the server knows that the user has provided a valid username and password it would normally do something like storing the user’s user_id in the user’s session. Then in the response to the browser or mobile app it would send back a cookie with the user’s session_id. Then in subsequent requests, the browser or mobile app would send the cookie to the server instead of sending the username and password with every request.
The other way to do the authentication, which I am less familiar with, is basically for the user to authenticate against another service like Google, Facebook, Twitter, GitHub, etc. and then get a token back which your app sends to your server to say “Google says I’m such and such a user”. In your database you’d e.g. store a mapping of email@example.com is user_id X. If you do it this way you don’t need to store the usernames/passwords in your database, so even if your server gets hacked, there are no passwords to steal. There are a few different protocols for doing this sort of thing. The most common these days seems to be OAuth2 + OpenID Connect. In your app you’d use something like this guide. On the server it would depend on what language and framework you’re using. I have never implemented this myself, on the client or the server, so I’m not sure I’ll be much help if you decide to go this route.
The username/password option is definitely easier to implement.