I have some PHP pages that receive POST requests and make CRUD operations in my MySQL database...
I would like to know if there is a way to allow only my Android application to do those requests in my pages...
As my application requires Google Login (which Google IDs are already registered in my database), I was thinking in check if client's Google ID exists on database via PHP script, but it could be faked, right?
Is there any other way to allow only my Android App to make CRUD in my database? Maybe using another language beside PHP
Thanks in advance
I would like to know if there is a way to allow only my Android application to do those requests in my pages...
This is an impossible request.
You cannot guarantee that end users are using your application to send data to your server over a public network (i.e. the Internet). Full stop, not gonna happen.
What you should do instead is ensure your server-side code is written to where, regardless of what data is hurled at it, your server doesn't get hacked.
I would store a secret key in your app and send that along with the request to log the user in. This secret key would be stored on the server and compared at login. If the key matches and user is authenticated then log user in.
Related
I have some PHP pages that receive POST requests and make CRUD operations in my MySQL database...
I would like to know if there is a way to allow only my Android application to do those requests in my pages...
As my application requires Google Login (which Google IDs are already registered in my database), I was thinking in check if client's Google ID exists on database via PHP script, but it could be faked, right?
Is there any other way to allow only my Android App to make CRUD in my database? Maybe using another language beside PHP
Thanks in advance
I would like to know if there is a way to allow only my Android application to do those requests in my pages...
This is an impossible request.
You cannot guarantee that end users are using your application to send data to your server over a public network (i.e. the Internet). Full stop, not gonna happen.
What you should do instead is ensure your server-side code is written to where, regardless of what data is hurled at it, your server doesn't get hacked.
I would store a secret key in your app and send that along with the request to log the user in. This secret key would be stored on the server and compared at login. If the key matches and user is authenticated then log user in.
This is more of a procedure question question than a code fault one so please be kind if I have posted in the wrong place.
I have successfully authenticated a gplus user client-side so the browser is holding the google id ready for me to use. I now want to post some data to my website with that id as the user id but i want to protect it meaning I don't want just anyone with someone else's gplus id to be able to post to my web app (it has to be the authenticated user at that time).
Should I install the php serverside sdk and use that? If so how do i merge the client-side data with that?
Thanks
You're absolutely right about wanting to get the ID in a secure manner to make it hard to impersonate. There are two main options, both properties of the authResult object that comes back to the sign in callback:
Send the 'code' to the server. This is part of the OAuth 2.0 flow, and can be exchanged on the server side for an access token. From that you can make API calls as the user, and retrieve the user ID and other details. You can be confident who the user is, as only Google could have generated that code. This would involve using one of the client libraries to handle the token exchange.
Use the id_token. This is a base64 encoded blob of JSON which includes the user ID (and email address if you requested the 'email' scope). What makes it secure is that it includes a cryptographic signature, which the server can verify, so it cannot be created by someone other than Google. The id token can be used to get the user ID, and so can be used for looking up the user on the server, but doesn't give access to make API calls. The benefit is that it only requires up to date certificates for verification which don't change that often, so most calls require no further network traffic from the server to verify the user.
Which you use is up to you, but both will require some code on the server. In general, if you don't need to call any Google APIs from the server, or are concerned about maximum login performance then use the id_token. There's a bit more about that sort of architecture here: http://www.riskcompletefailure.com/2013/11/client-server-authentication-with-id.html
You can even combine the two. The first time a user signs in (when they see the consent screen) the code exchange will return not just an access token (for making calls), but also a long-lived refresh token, which you can store securely in a database. If you store that, you can use the id_token to look up the user quickly, but still use the refresh token to help with API access.
Im going to make an app that will be able to sync data between android mobile phone and a webpage database. At the moment im trying to think things through and figure out the hard parts. The first thing that crosses my mind is the login part.
The best idea i have is that before starting my app user has to log in. When he logs in it sends user data to my web page and it returns true/false. If it returns true i make somekind of an session in my app that says i am logged in (to access app features) but also stores my username and password. Now if i press the sync button or do something else that will need communication with my webside i can check the user/password every time. Because on the web site im planning to do different actions (login, sync, something else) i need to check the login every time - otherwise a third party could just access sync action without actually logign in first.
Anyway, that my thoughts at the moment. Im sure ill ask more detailed questions when i get to coding (im a beginner with android/java) but at the moment i wish to know if the idea of the thing is good or can it be done smarter/better?
Thank you.
I'm suggesting you to create API based application so you won't be troubled if you want to create it in many platform (in case you also want to create in iOS).
What I'm usually used is using API_KEY. API_KEY is a random number generated by the PHP side to save the login session of the user. When the user login from the mobile phone (sends the username and the password) the PHP side will generate API_KEY and updatethe existing API_KEY (if the user have logged in before in other device) in the web database so the login session in the other device will be automatically expired but you must add API_KEY validation everytime you try to access the the database (sync your application) or if you want more strict you can do the checking everytime the user change the screen.
If you have some question about this feel free to ask in the comment ! :)
I am developing a Google Marketplace App. I am using PHP.
I am trying to have an access point to my app which doesn't require the user to have logged into my app (or possibly even Google Apps for that matter), and then once they have submitted the entry point (which just consists of a string) that string is carried through the authentication process so that when they authenticated my app can process that string just as if they had been logged in.
Basically I have a HTML form which is like a cut down version of my app (which can be embedded on a website using an iFrame for example), and when the user fills it out it does an AJAX call to an API in my app which does require authentication, so the authentication process begins, but once it has finished it has lost the original data.
Does anyone know a solution to this?
I am not sure that you need to use Sessions for this - might be overkill. I am not sure the exact specifics of your application, but you might be able to place the data in the $GLOBALS superglobal. Take a look at the documentation:
php.net/manual/en/reserved.variables.globals.php
I ended up using sessions however it was more tricky than usual because the authentication occurs on a different domain to the access point to the app. What I ended up doing was encoding $_SESSION and storing it in a database, and then when the authentication has occured and the app is logged in it checks the database for any sessions and restores them.
I am working on builing an API and application section on a social network so it will be something like myspace, facebook, hi5, friendster, netlog, and many other's have application section, they all use a REST server method and most of them will issue a api key and secret to each application developed. The person who builds the app will pass the api key and a user signature that is created with a hashing algorithm based on the user's ID who is using the app and the apps' API key. The applications code should set a cookie with some information like user id and signature and time. So on my server end the REST part should I just build the signature the same way the app does, check to make sure they are the same, if they are I send the correct data back. My concern is, how do I make sure a developer does not set a user's cookie to keep them authenticated for a long time, should I compare the time the users signature was created and if it is like a day old then I will send a bad response back from the REST?
When a user first add's an application from my main site, I will load the application site into an iframe and I will pass in user ID and other fields where I include the iframe so the application can use GET to initially get the information it needs to set it's cookie.
If you can help on this issue I would appreciate it, does it sound like I am in the right direction so far?
BTW I am using PHp/MySQL
I would store the token & user identifier that you pass back via the API in a database with a timestamp. When the user checks in via API to authenticate, check that timestamp and see if it is too old. If it is then pass back something like FALSE which would trigger some other command to make them re-authenticate into your system, which in turn would generate a new api token for the user to use.
Store a time() value in a session and every time the user does something check that time value to see if it's been longer than X minutes.