I am in progress of creating an Android Application which should have ability to share content with other users and I am planning to use PHP backend.
I want users to log in to my web service to avoid trolling and filling my service with useless data.
But now that I am using Android to access the service, I know its simple to create a HTTP post and send the login credentials to server but how to keep the session alive?
As far as I know its common to just keep the application logged in to the service with mobile phone, at least when there's no personal data available.
How should I store the data that Android device has been logged in?
Lets say I created a MySQL table that would contain the user, password and id.
I thought about generating unique id for the device, using ANDROID_ID or IMEI and associate it with the user id that has been logged in my web service, but that doesn't seem secure enough.
How does other applications do this?
You can continue to use a session if you read the cookie from the first server response (set through Set-Cookie) and send it in subsequent requests using a Cookie: header. Just the same way a web browser does it.
It depends on the HTTP library you are using, how it is done.
Related
We have an existing web application we developed and needed to port over to an android application for people in the field. So we have a shell of an android application that just points to the URL and displays it. I want to save the user credentials so if they timeout/close application and re-click the application it will auto log them in always after the first time.
I am looking at SharedPrefrences as other threads here have done, but not sure how to capture the creds from the web input elements. Can I use SharedPrefrences to accomplish this still? If so how do I target that input?
You do NOT save the user credentials. Ever. Saving them means they can be read by malware. And no, encryption can't help as the encryption key would need to be in your app or on your filesystem.
Instead, you have your login API return a token. This token will be sent back to the server with every request (either as a parameter or a cookie). The server will then use this token to look up the user id on the server and figure out who it is. That token can be saved to SharedPreferences. (This is the simplest version, there are more advanced things you can do as well, but this is sufficient).
Why is this safer than storing the password? Because passwords can and frequently are shared between multiple apps, so losing a password can compromise multiple accounts.
BTW, this is also how webapps work. They don't send the username/password with every request, when they login a cookie is saved with a token, and its sent back with every future request.
I have a Java servlet (running on Google App Engine Standard) talking to a Flutter client that is also logged into Firebase. Can the Java servlet detect which user is logged in perhaps by using the admin SDK to read the HTTP headers or cookies? I can't find such a method in the SDK though. I guess the question is about having a Firebase client that talks both to Firebase and to other cloud services.
(I saw the servlet can talk to Firebase https://cloud.google.com/solutions/mobile/mobile-firebase-app-engine-flexible but my question was more simply if the servlet can verify which user is signed in)
Thanks!
The backend (it doesn't matter what it is) can't read anything directly from the client if the client doesn't pass that data along. Typically if the client using Firebase Authentication wishes to identify the user to the server, it will pass an ID token to the backend, usually through a header. The backend can then use the Firebase Admin SDK to verify the ID token. The ID token should be available in every request send to the backend where identity needs to be known.
I'm currently working with a backend service, which is allowing users to log in using the Google Games library on a client application.
The user can send us through their gplay id in order to log in, or restore an old account. Including their gplay id, the user is sending us the following;
GPlay ID: gxxxxxxxxx
GPGS client id: xxx-xxxxx.apps.googleusercontent.com
GPGS auth code: 4/xxxxxxxx
message_salt: <ByteString#xxxxxx>
Is there any way to use the above data on the server, and verify that the user owns the GPlay ID that they are sending us?
Currently, I'm not seeing any way to authenticate the user's ownership of their GPlay ID - nor am I seeing any obvious way that it can be compared against their client id or auth code to ensure that the user's request to log in/restore an account using their GPlay ID is legitimate.
Does anyone know of any way that you can verify a user with the above data?
The server auth code is the only piece of information you need to send from the client to your backend server. To use the server auth code:
Associate your client app and your backend server app to the same game definition on the Play console.
When building the Google Sign-In configuration, add the requestServerAuthCode() option, passing in the client id of your backend application.
Once the user authenticates, get the serverAuthCode from the GoogleAccount object.
Pass the authCode to your backend server.
On the server, exchange the auth code for an access token. This token is specific to your application and the user. Save the refresh token on the server in case you need to refresh the access token.
Once you have the access token, verify the token by sending a GET request to www.googleapis.com/games/v1/applications/<app_id>/verify/. This returns the information about the authenticated player.
There is a sample of both the client and server side code at
https://github.com/playgameservices/clientserverskeleton
I have a running J2EE based Web Application for Point of Sales hosted in cloud and database is using postgresql. Now I am building an android app for Point of Sales. For data sync I have read a lot how to create SyncAdapter etc but very few about server side developments. My first question:
How the authentication token will be created? Who will create this AuthToken? My server side RESTful webservice or Device SyncAdapter itself? Who should initiate expiry of AuthToken - the device or server webservice?
Currently my web application got many user level permission. When a data will come from device to sync I need to check the user permission before sync. Do I need to custom write these permission checking inside my server side webservices?
In short the server is responsible for creating an AuthToken. For a better understanding you should read the OAuth2 specification. Although you could write your own simpler solution, I recommend to you that you use OAuth2 to avoid some pitfalls. In your case authentication grant type "Resource Owner Password Credentials" seems most appropriate. Apache Oltu is a framework for implementing OAuth2 in Java, but you still have to handle some things like persistence of tokens on your own.
Yes, you have to the check the permissions on server side. Don't trust the client! Besides that you may restrict the apps more strictly by using different token types in Android. For example: When you're accessing the web service from within your server application and from Android apps, you could differentiate permissions based on the token type (Android vs. internal). Or maybe you provide your app's users an option to restrict the app's access only to read operations.
I am getting confused.
I have to write an Java Serverapplication for an mobile application. We have our own user management in that application, meaning the user can register and login on our servers without using an OAuth-Provider at all.
Now I want the user to be able to alternativly register via an OAuth Provider.
These are the options I see:
Let the user register local only.
Advantage:
The mobile applications can use the frameworks which are able to login and retrieve an access token for our application
Everything is prestyled by the platform itself, so no GUI work on that
Disadvantage:
How does the server know if the user is logged in or not? One way to figure that out could be to send the access token to the server and let the server start a request to the provider to check if the token is valid or not.
For the registration I have to send all user information which the client got from the provider to our servers.
I dont like this option, cause I would send Userdata and Accesstoken arround. Yes, it would be crypted via https of course, but it just feels wrong.
Let the user register via our servers
The user requests the OAuth provider itself to retreive the code with which you could request the access token.
Send this code to the server and let the server retreive the acess token.
Advantage:
The Server can be sure now, that the user is logged in
The server can retreive all user specific information about the user (such as username etc) from the OAuth provider itself, without sending the arround.
On a login you can repeat this, to make sure that the user is logged in correctly
Disadvantage:
I have to write the OAuth connectors (or using some library for that)
We are not able to use the sdk's, cause they're just returning the actual access token.
We still prefer the first option (register local only)
Because
they WANT to use the sdks. "'cause everyone does it."
If the user would start the application the first time and he was logged in already (with i.e. the FB client), he just has to accept the scopes, we setted up for our application.
Easier to handle the actual login, cause the sdk's where made for it
Does anyone know how to do something like that correctly? Both solutions seem a bit wrong to me.