Firebase.Auth.FirebaseAuth.SignInAnonymouslyAsync()
It is a question about anonymous user (FirebaseUser) returned by the above function.
I am creating iOS and Android applications with Unity.
Is the "FirebaseUser" returned by "SignInAnonymouslyAsync()" always the same as long as a user is using the same mobile device?
Also, what is the condition that the returned "Firebase User" is always the same?
The user is always the same unless the app is uninstalled and reinstalled, the app's private data was cleared, or you sign out the user. In any of those cases, the previous anonymous user token is lost and a new one is generated.
Related
I have an application defined in Okta. Both app and users are assigned to the group, yet when user tries to login he gets access denied: Message contains error: 'access_denied', error_description: 'User is not assigned to the client application.'
When user is assigned to app directly, then it can sign in. But should not it work with the group?
Yes, it should work regardless. Are you able to see the application in the list of assigned for your user, when you check in Okta UI? Maybe the group is large, so it takes time, when you assign a large group to the app. Or when a group is assigned to a lot of apps. But in the end you should be able to see the app in question in the list of apps. If it's the case, then something wrong is happening here. Might worth open a ticket with Okta Support. If you don't see the app there, then you do something wrong
I am wondering when in an app lifecycle to update the FCM registration token. I am using Firebase React native.
Currently, I send the FCM token to my backend:
on every app start
in onRefreshToken
sign in/out actions (to associate a user with the token)
I am wondering whether the above list is comprehensive and whether it contains extraneous update hooks (for instance, I am not certain that updating on every app start is necessary).
Main concerns revolve around:
what happens if the device loses access to the internet in onRefreshToken and the backend fails to be updated about the token refresh?
what happens if the FCM token gets refreshed when the app is not running? (and, hence, onRefreshToken is not invoked?
In summary, what is the officially recommended way to notify backend of updates to the FCM tokens?
because of the complexity of this and the difference depending on the application I have never seen an official recommendation, but a few things to add:
store the token on the device (e. g. shared preferences) to make sure you always use the latest or ask for the current one each time you need it
if it is critical you can store the state after an updated token and re-try more often if it has not been successfully transmitted.
on every app start is usually a good solution as fallback because many things can happen
consider logout without internet or uninstall. Here you will not remove the token on the server, so the next user could get the message without measures against that.
implement an update-process on the server to handle error-responses
I'm setting a session value in one app and it's not available in any other app once the redirect happens. It's available in the source app (the one where the value is set) though. Is this expected behavior?
I've inspected session IDs in the origin app and in the target redirected app and they are different. So how can/should I pass the session variables from one app to the next? I need this for setting the authenticated user and currently it doesn't work due to this behavior.
Kind regards
Seba
The problem was that I was using different session secrets for each app. When using the same session secret, it works as expected.
Seba
this is a generic question. I want to know about httpcontext.user.claims. How this is getting its value? Is this session dependent? will this be automatically updated when a session expires?
Our web app is a federated app inside another app. That app controls the logging in part. so once they are logged in the user can access our application and they send us a particular value needed for us through query string. we validate that value against the claims values by accessing httpcontext.user.claims. SO now the problem is inside our app httpcontext.user.claims has still the values of previous logged in user, if the browser is not closed or we havent cleared the cookies of the browser. SO its impossible for us to validate when logged in with another user from their app without closing browser or clearing cookie.
So i ant to know whether the httpcontext.user.claims is session dependent. Also when logging out they are actually doing session.Abandon() when they call logout method. Is it because our web app is creating another session, but we have no code written for any new session creation. F
My application has some features that are accessible to all users, and some other features to which access should be restricted to authenticated users only. All these restricted features exists within some set of GWT Places, thus, all Places available in application can be divided into two groups: "accessible for all", and "restricted". In my opinion, places with restricted access, could implement some interface (let's say it would be RestrictedAccess), and if user proceeds to one of them, and it has not been authenticated yet, it will be redirected to the login screen - it's more OO-approach than applying filters basis on URL.
What I'm trying to achieve is:
Information about if user has been
authenticated or not should be
stored on server (it's not something
that could be stored in a cookie...)
Login page is a standard GWT place+view+activity (!)
User name & password validation is done on the server side.
So far, I've introduced RestrictedAccess interface, which is implemented by some set of places. My FilteredActivityMapper.Filter implementation, which is passed to the FilteredActivityMapper wrapping application activity mapper has the following logic:
Place filter(Place place) {
if (place instanceof RestrictedAccess && !userHasBeenAuthenticated()) {
return new LoginPlace();
}
// return the original place - user has been already authenticated or
// place is accesible for all users
return place;
}
private boolean userHasBeenAuthenticated() {
// remote call - how to do ???
}
The problem is with userHasBeenAuthenticated() method (user should not be redirected to the LoginPlace, if it has been already authenticated). If I want to store this information on the server-side, I have to do GWT RPC/request factory call here, but both are asynchronous, so I cannot work on its result in the filter method.
I know that I can use web.xml filters or some external framework (e.g. spring security), but none of this approach allows me to have login page as a standard GWT - based form, or indicating in the more OO way that access to some place should be restricted.
Thanks in advance for any hints
EDIT: I've started to wondering if places filtering (restricted/not restricted) should take place on the client side at all. If, as it was suggested, there is a possibility to hack code indicating if user has been authenticated or not, there is also possibility to hack places filtering code, so that it will be possible to access restricted places without signing in.
Piotrek,
I think there is a security issue with calling userHasBeenAuthenticated() - it would be possible to hack the client side code to return true every time this function is called.
The solution I've implemented is to simply return SC_UNAUTHORIZED if an unauthenticated user attempts to access any remote service. I've overridden the RequestFactory onResponseReceived function which redirects to a login page if the response is SC_UNAUTHORIZED. Idea taken from:
http://code.google.com/p/google-web-toolkit/source/browse/trunk/samples/expenses/src/main/java/com/google/gwt/sample/gaerequest/client/GaeAuthRequestTransport.java
This works for our situation where the Activities and Places are all data-centric - each place change retrieves data from the server. If a user isn't authenticated they simply don't get the data and get redirected to a login page.
I realize your situation is slightly different in that some places are accessible to everyone, in which case you could configure only the restricted services to return SC_UNAUTHORIZED.
I have a similar application with the same requirements. As yet I have not got round to to the implementation but I was thinking along the same lines.
What I was planning on doing is storing the authentication state client side in an AuthenticationManager class. When the app starts I was going to request the login info from the server (I was thinking of running on app engine so I would get the authentication state and also get the open id login/logout URLs) and store this in the AuthenticationManager. Acegi/Spring Security works in a simlar way so this info is available server side if you use those too.
When the user logs in/out they will be redirected by the server and the new state will be retrieved. This should keep the client authentication state in line with the server. Each RPC request on the server has to be checked for authentication too. I was using the gwt-dispacth library and this has some rudimentary authentication checking and cross site script protection in in too (although I think latest GWT has this for generic RPC).
One issue is session timeouts. Again the gwt-dispath library has some code that detects this and returns session expired exceptions to the client which can be intercepted and the auth manager updated.
Hope that makes some sense.