Authenticate on a single mobile or device

clear
only if you have the email and password
In this case these two would be hidden

I'm also testing

Replace the value on/off with a timestamp of when the user has signed in, somewhere. (Firebase provides a timestamp function)

When the user attempts to sign in from another device, test the current time against the timestamp, if the current time is +1 hour from the stored timestamp, then allow sign in to continue (assumes the previous user has not refreshed their IdToken and updated the timestamp to continue their session). Given a user is unlikely to try signing in on two or more devices at the same time, they should only be able to be effectively signed in once.

What do you think...

:question:

Could you put it into blocks?
I'm a newbie

Thought you might ask for that. I will work something up later.

Not as much work to do as I thought. You only need to make a few changes to the blocks I previously provided in my example. You will also need to drag in a clock.

Worst case scenario is that the user would have to wait up to 1 hour before they could sign in (e.g. network loss / turned off device etc.)

You may need to put an out of date timestamp in each of the uid values when they are created.

I think we are confusing things, the problem is with these 2 examples

example 1
when trying to open from another device.
(this was solved with the previous example of off and on)

example 2
when the app is closed by chance without having logged out.

This example sent is so that it cannot be opened from another device, that is (example 1) it seems to me that it is the same as saving in (on and off) previous example only varies in the saved time

How does it help me for example 2?

I had something in mind like this

On screen1
When logging in, save the (User Uid) in tinydb on the mobile

and when the app is closed for X reasons without logging out

when you reopen the app on screen1.

The session of the last user who registered is closed using its Uid that was saved in the tinydb

what do you think?
What could go wrong?

The uid is unique and persistent for the user, it does not change, so all you are doing is the same as before, which negates the entire process, given that you have to sign in in the first place in order to change on to off.

You cannot actually close another session if the user has signed in to firebase on another device with the REST API.

Your requirement probably needs to be run through a web browser using the Firebase Admin SDK so that session can be revoked. This is probably possible, but requires a lot of work with the webviewstring to capture and send information.

In this case, if I log out when starting the screen with the Uid and Token saved in the tinydb

You are right, the Token is the detail because it changes from time to time.

Question: How often does the token change?

The idToken will expire after an hour, but everytime you signin, on the same device/session, you get a new idToken and the hour restarts.

Done a bit more thinking. You can do what you suggest by storing the timestamp created to tinydb. Then if user doesn't sign out or network is lost, on the next attempt to sign in, test the value of the timestamp against the one stored in the tinydb, with an or for the timestamp being less than the current timestamp.

If the timestamp values are equal, then this should indicate a failed sign out by the user on that device, and sign in should be allowed.

This will of course only work on the specific device, sign ins on other devices will be subject to the the timeout test as before, because their timestamps will not match.

Of course I understand

but in the last block you sent where we save the time. It only saves me in the session exit. You didn't send it completely, so I didn't test it 100%.

on the other hand
With this method will we depend on the Token?

since generally when the power goes out it goes out for more than 1 hour and after that the session will remain open

Could you put it into blocks?

attached .aia
just to add the
fbUrl and fbApiKey

simultaneo.aia (11.4 KB)

There is no point in using the idToken, because trying to sign in on a different device will not be possible, in the same way as on/off works.

If I get time, I will expand my previous blocks to include the latest suggested method.

1 Like