authenticate on a single mobile or device
I have an app that when installed on different phones I can access all of them at the same time
I would like to restrict it so that it enters only one mobile at a time, not more.
these are my blocks
Firebase Authentication doesn't provide a native method of doing this, nor is it necessarily easy. The simplest solution I have found is here:
but is for javascript, not the REST API that we use in AI2, although the approach seems sound enough. It looks like you have to allow the "second" signup, but then test for a previous signup against a value in a tag. If a signup already exists, then in the app you signout the second signup. (signing out users with the REST API is also problematic..., so easier to do it in the app). You would also need to signout the first user in Firebase and reset the database tag.
You might also be able to do something with the refresh token.
You would also need to handle situations where the user does not bother to signout.
You could switch to using some html and javascript to make things all happen at the firebase end.
Bet you are glad you asked 
If I get some time, I will do some testing.
As a complete alternative, you may be interested in this:
OK, you could do something like this:
You cannot avoid signin to Firebase, but you can then handle what happens...
- In your SignUp process you will need to add the uid and an on/off value to a node (I called mine
usus) like so:
You do this for each individual user, their uid remains the same across logins.
-
A user signs in in the usual way, but with these blocks, a call is then made to firebase to check the value of their uid in usus.
-
if the value is "off", then the user is signed in, and then another call is made to firebase to set their uid value to "on".
-
if the value is "on", then the user is advised that they are already signed in somewhere else, and the uid and idToken are cleared in the app.
-
the user must sign out at then end of their session, which sets the uid value back to off. I have not handled all the issues of a user not signing out, this will be important because otherwise they will not be able to sign in at all after their token has expired. There is then more work to be done.
something is wrong
ask?
*when I log in it should automatically create me:
tag:value
User UID:"off"
in addition to obtaining the value in Label1
well it doesn't
Label1 responds with null
*when I log out if you believe me
tag:value
but not what was desired since it apparently creates another token
From what I understood is that the token should be kept and when:
login should get "on"
I log out I should get "off"
is this true?
This is what you would want, yes.
Have you added three different users with different email addresses ?
You will always get an idToken when you signin, otherwise you cannot get the tag value, and then let the device decide what to do.
Here is a blank aia project for you to play with
fbSingleSignIn_blank.aia (4.8 KB)
The labels are just there to give confidence that the correct thing is happening. Remove the label blocks, if all is well.
The detail is that you would have to obtain a list of users and passwords when starting screen.
to compare them with:
the username and password text field and thus be able to enter
to avoid putting
email and password in the apk
That's right?
On the other hand, the btSignOut button
I would have to be on another screen to be able to log out.
No, when a user signs in, they get back their uid, this is used to test the value in usus. You do not need anyone elses details.
That should not be an issue.
I don't want to put this in the apk because it conditions and limits me
and created ["users","passwords"] on FB
so as not to be putting in the apk
The idea is to obtain these values, compare them if they exist and thus be able to enter by going to the next screen
I can't find any other way to avoid putting the email and password in the apk
My blocks
are for example only, to show you where the email and password go in the PostText.
In reality, your user would type in their email and password to textboxes, and you would use these in the Posttext block.
Yes, that is the idea.
Your users must have a lot of confindence in you and your app, that you do not misuse their user and password information
Anorher possibility would be to use an email account especially for your app and send all emails from that account without need to enter user and password
Taifun
I have a couple of doubts
1 I would like to close the session from screen2 with a button that at the same time returns me to screen1 to start again
I understand that Label1 content is important
Would I have to take that content to other Screens to be able to log out?
2 as return of (on a of in FB)
when the power or network goes out or if by chance I close the app in some other way without logging out
user trust if it exists
The detail is that because it is an app on a mobile phone, it is easy to be manipulated by external agents who own what is foreign to be clearer (THIEVES) I am from PERU and here there are all kinds and I believe that the same thing also exists in other countries.
That's why I try to be careful with the information.
-
Yes, you will need the values of global variables
fbUrl, idToken and uidon your other screen. easiest to save these to tinydb, and use tinydb with the same namespace on your other screen. -
You may need to use an activityLifecycle extension to send the signout when the app goes to the background. Not sure there is much that can be done if network (wifi and data) both drop out at the same time. Perhaps an admin app or other server that periodically resets all user uids to off.
Answer 1 OK
screen1
screen2
Answer 2
I already tried it by closing the application without logging out and when I log in again it doesn't allow me because it is "on"
I need a small block on screen1 that when starting screen closes previous sessions and puts them "off"
I have the email and password in tinydb, this will be kept on the mobile to close the last session
This seems the most appropriate before thinking about an extension
I believe we have found the downside of this approach. Doing as you suggest above, negates the point of doing any of it, because it would mean that any user/device/location could then sign in...
I will give some thought to another method.