I have problem with keeping user logged in to AWS Cognito in my android app. This is the code which checks that:
CognitoUser user = AppHelper.getPool().getCurrentUser();
username = user.getUserId();
if(username != null) {
AppHelper.setUser(username);
inUsername.setText(user.getUserId());
user.getSessionInBackground(authenticationHandler);
}
The problem is that sometimes (I guess after some time) the app forgets the user and that code:
user.getUserId();
Returns null. However that is never null:
AppHelper.getPool().getCurrentUser();
My code basis on the code from the sample app so I cannot understand why it doesn't work. I though that there might be a problem with Cognito pool, so I changed in devices options to always remember user device, but the issue didn't disappear.
Hi Grzegorz Brzęczyszczykiewicz,
user.getUserId(); will always return the userid, if the referenced CognitoUser object was created with CognitoUser user = AppHelper.getPool().getCurrentUser(); after a user had previously successfully signed-in.
An explanation for the behavior you are seeing could be that the user was changed to reference a CognitoUser object which was not set to any user. This can happen when CognitoUser user = AppHelper.getPool().getCurrentUser(); is executed after clearing app data on the Android device.
Can you give provide any more details about your app, to better understand the issue? When the app executes user.getSessionInBackground(authenticationHandler);, are you able to successfully sign-in?
Related
I'm using Firebase Auth in my app. I wrote code in onStart().
private fun checkLogged() {
if (Firebase.auth.currentUser != null) {
startActivity(Intent(this#LoginActivity, MainActivity::class.java))
finish()
} else {
auth.signOut()
}
}
But when I disable or delete this user in the console, It's still logged in. How can I edit code correctly?
When a user is successfully signed in with Firebase, then it receives a token that is valid for about an hour. If you disable a user in the Firebase console, it doesn't mean that the access is restricted too. No, the user can still have access for about an hour. After that period of time, the token that was previously generated needs to be refreshed, but the operation will fail since the user account is disabled. A disabled account cannot get a new token. So the user can still have access until the access will be automatically revoked.
If you want to remove that access before the token expires, then you should consider keeping an additional list of "banned" UIDs and maintaining it over time. For example, you can keep a global array of bannedUIDs in a Firestore document, and add the UID to that array. Then, in your security rules, you can check if that particular UID is banned or not. If that UID exists inside that array, then Firebase servers will reject the operation, otherwise, it can continue to use your app.
In my Android app, I use AWS Cognito to allow my users to sign up and login. I configured my identity pool so it allows guest users (unauthenticated users) in my app.
So everytime my user logs in or logs out, I call the following code to get an identity ID:
CognitoCachingCredentialsProvider credentialsProvider = new CognitoCachingCredentialsProvider(
this,
"eu-central-1:12345678-1234-5678-9012-1234567890ab",
"eu-central-1");
credentialsProvider.clearCredentials();
credentialsProvider.getIdentityId();
When my user logs in, it creates a new identity the first time, then the user gets the same identity everytime he logs in. But everytime he logs out, a new identity is created, since he's now a "guest" user.
Is that the expected behavior? And if yes, how can I remove an unused identity programmatically (for example when the user logs in, so the "guest" identity is now useless, since a new one will be created when he logs out)?
Thanks for your help.
From the docs, we have:
getIdentityId() Gets the Cognito identity id of the user. The first time when this method is called, a network request will be made to retrieve a new identity id. After that it's saved in SharedPreferences.
clearCredentials() Destroy all the saved AWS credentials but not the identity Id.
so, the behavior you described is totally normal according to the docs.
Now, let's find an approach to deal with the problem.
if you want to continue with your proposition, and delete the identity programmatically after the logout, you can use deleteUser() method from AWSJavaSDK.
However, if you want to keep the same identity for the same user after the logout, you shouldn't clear the cache, cause the won't keep the user any trace of its identity.
I hope this will help.
I encountered a very strange error when signing up a user using android 6 on a specific device.
The signup process works perfectly and the user is registered on Parse database. The code checks and if ParseUser.getCurrentUser() != null then the app sends the user to the main page and this all works till here.
However, I noticed that user is not able to send any requests to the server and it all rejects in the main activity and user can't even logout. The error I receive when logging out is:
com.parse.ParseRequest $ParseRequestException: This user is not allowed to add a field to _User. You can change this setting in the Data Browser.
It seems like the authenticated user object is not matched with the original user's token on server and that is why this user get ACL errors.
I am using Parse default signup and login functions and this has happened only on one device using android 6 so far. Any guess on what could cause this issue and how can I resolve this issue?
ParseACL roleACL = new ParseACL();
roleACL.setPublicReadAccess(true);
Add these lines after the user Parse.initialize() function. It allow user to create column in the table from mobile. Make sure the user is logged in otherwise it gives error.
Hi I'm trying to implement a new app using Parse login with facebook feature.
I followed the Guide to use facebook login feature and all went ok.
Documentation states
Sessions represent an instance of a user logged into a device. Sessions are automatically created when users log in or sign up.
The problem is that I never get a valid session token when ParseFacebookUtils.logInWithReadPermissionsInBackground(...) returns (and signs up) a User which is newly created on the Parse platform (thus User.isNew() is true).
Inspecting the Data dashboard I can see correctly the new _User entry but there's no entry for _Session class, whereas I should find the one with createdWith="signup" for my _User.
As a side effect when trying to logout a newly created user i get a com.parse.ParseException: Parse::UserCannotBeAlteredWithoutSessionError because, obviously, the newly created user doesn't get any session token.
If instead I perform the same operation for the same user after its creation (and therefore the User only logs in into Parse) I get a valid session token and everything's ok (which means there's a _Session object with createdWith="login" associated with the _user object).
Is this a bug or something not expected to occur? Or am I missing something?
Thanks!
Currently using:
facebook-android-sdk:4.0.1 +
ParseFacebookUtilsV4-1.9.1.jar +
Parse 1.9.0 jar
I was successfully making an FQL query earlier today. Now when I try to make the same query I am getting the following message.
"error_code":190,"error_msg":"Error validating access token: The session has been invalidated because the user has changed the password."
I am making the query on my own account, and my password has not been changed. Any suggestions for why this may be happening?
Now I am getting this error.
"Error validating access token: Session does not match current stored session. This may be because the user changed the password since the time the session was created or Facebook has changed the session for security reasons."
Based on above comments, this will be this issue.
The Single Sign On (SSO) in Android allows a user to authorise your app, and once they have done that they will be signed straight in on subsequent visits if they've signed in to Facebook for any application on the phone/tablet.
The downside of this is that the SSO remembers the token and if the token becomes invalidated (by a user de-authorising the app or by them changing password or other details), it will try to use it anyway. You MUST check for those two errors specifically as "isSessionValid() will return true, even though it's not. If you catch one of those two errors, you call the authorize method again.
So, in your case, trap that error, and call authorize().
Documentation from Facebook: http://developers.facebook.com/docs/mobile/android/build/#sso