Keeping users logged in from their mobile device to a webapp to clock in and out

[Jaume Aragay]

Hi there,

I'm volunteering for an NGO dedicated to Cerebral Palsy . I'm building a contactless version of a clocking app I did for them, before covid, on a Raspberry Pi that sent the data to a G-Suite (from now on, GS) environment. 

Because of the covid, being the NGO's main activity a residence for high risk individuals I have to make the contacless version of the clocking app and I thought of using a GS webapp where everyone clocks from their own mobile phone from the residence's wifi to make sure they are there when clocking (I check their IP with the webapp).

WHERE IS THE PROBLEM?

With user identification. 

1.- I tried with GS user vars but the NGO does not have the free GS environment with a user for every worker in their domain (as they don't want them to have an email from the NGO) so I can't use the user-related variables in G-Suite to "keep them logged in" so they only have to open their app and clock in or out. I tried but as all the users run the app as the same user (in the NGO's domain) and when using those vars to keep track of who was using the app the users' states (in or out) got merged.

2.- I tried with localStorage in the browser, but with the final app in an iframe at their website where, again, the workers dont have a user defined as it's not an intranet but just the NGO's website, it doesn't seem to work either.

3.- PHP and Session linked to GS? Other alternatives?

I'm running out of time as they are already supposed to be using this "contact less" clocking app for security reasons to help prevent covid in their facilities. I wanted to make the change during these holidays and I just have to solve this "login and remember me" problem where I'm stuck. 

Now I send them a link with a unique identifier that retrieves their info from the GS Users Sheet the first time they use it. The problem is where to keep this info secure for the subsequent times times they enter the app. If they "lose the connection" I can send them a new email with a new identifier to repeat this initial process, but not require them to do it twice daily in order to clock in and out. They won't use it. I wouldn't either! ;)

How would you face this problem? How would you identify each user (and keep them identified as long as they don't log out explicitly in their own device)? If I add a var to the app's address and process it with doGet then they could clock for someone else as long as they have the other user's var value... And having them login twice a day to clock in and out does not seem a good enough option.

Maybe if I could get a unique string identifying the mobile phone from the browser I could check that that phone is associated with 'user1' and warn them if they try to log in as 'user2', but I haven't found a way to get this sort of MAC address for the mobile phone used to associate it to the user's profile. I found the way to get their IP, but not info related to their mobile phone.

I'm not asking for a fully developed solution, but just for your suggestions on what to use to keep them logged in or at least identified in their mobile phone without access to GS user vars as they all run as the same user but not allowing them to cheat as most of the office's workers are doing remote work so no one can control if the people going to the residence is there or not and I can't ask them to be their own police and check on the rest of workers as they are doing a great job assisting the residents. 

Thanks in advance for reading this. I hope to hear from you soon.

Best regards, and have a happy 2021! ;)

Jaume.

[Alan Wells]

  So,

• You have an email address for every user that can be used to send them an email
• You can get their IP address.
• If you have a way to associate the email address with the IP then you can know who the employee is from the IP address.

Is that correct?

• I don't know why you'd need info related to their phone if you can associate the IP with the user through their email address.  You'd need to have a one time verification, which you stated that you have a way of doing.  You send them an email with a link, get the IP and get the information back.
  
• I don't think you need to store anything on their device if you can get the IP address.
• It good that you want a secure way to store the data that associates the IP with who the employee is.  That data should be stored somewhere this is only accessible to the app, and not the users.  Is the Web App storing information in a Google spreadsheet that is only accessible to the Web App?
  

[Jaume Aragay]

Thanks for your answer and interest! :)

I cannot use the IP to identify the users as the only way I can think of to make sure the users are there, at the building, is to make the clocking using the NGO's WiFi to "force" their IP address. The app is to log they work hours at the residence facilities, so I can't use different IPs for different users.

I'll think I'll give a go to the browser fingerprint idea and see what I find about it... I'll keep you posted.

Meanwhile, if you have any other idea, please tell me so.

Thanks in advance,

Jaume.

El dia dijous, 7 de gener de 2021 a les 18:20:58 UTC+1, aj.a...@gmail.com va escriure:

[CBMServices Web]

So it seems you need 2 things in your clocking. First is to authenticate who the user is and that should be able to be done by using their email address alone.

The second is to determine where they are. IP address would not work if you use the wifi IP dynamic address because all of them use private IP addresses behind firewalls and all of them could have the same fake address of 192.... What you can do is get a GPS location for them to confirm their location. Browsers support this and assuming your workers are ok with having location turned on their devices, then that would be feasible.

--
You received this message because you are subscribed to the Google Groups "Google Apps Script Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to google-apps-script-c...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/google-apps-script-community/6a31c6b9-ed4c-44b7-a121-aa5465f8c9acn%40googlegroups.com.

[Alan Wells]

Are you going to use fingerprint bio-metric authentication?

https://source.android.com/security/biometric

[Jaume Aragay]

1.- AJ: Not the user's bio-metric fingerprint but "browser fingerprint": It seems the list of plugins and javascript options make a unique photo of the device used. See, for example, this page https://amiunique.org/fp

2.- GEORGE: I don't want them to enter they email twice a day to clock. I wanted an alternative so when they enter the clocking page they are already identified (that's why I want to use localStorage at the browser or an alternative), then the location is checked so we know they are located at the building, where they have a fixed public IP, all I need to make sure they are "there". 

El dia dijous, 7 de gener de 2021 a les 20:22:23 UTC+1, aj.a...@gmail.com va escriure:

[CBMServices Web]

Well I guess ultimate authentication is fingerprint biometrics. 

But is this really being a little too paranoid on workers cheating and sharing their Google log on credentials with their co-worker's for malicious purposes.

This may be a little too far.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-apps-script-community/883cd81b-4846-434b-ae5a-5fc8ee0a4f45n%40googlegroups.com.

[CBMServices Web]

They don't need to enter their email address everytime. Google usually keeps you logged in to the browser unless you log out. 

The webapp should not ask for email addresses, you just check at the server who this person is via their credentials.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-apps-script-community/3392dea9-fb95-412e-8ac0-b97917055636n%40googlegroups.com.

[Jaume Aragay]

GEORGE: 

a) It's not NASA, it's an NGO, we can't/won't use bio-metrics, we just want each worker using his own mobile phone to clock in and out to avoid all users touching the actual physical clocking device at their reception counter to avoid covid propagation risks. 

b) Cheating is to be avoided because most of the workers give 120% of what is required and have done so for very long months to allow a different attitude on some of them.

c) The email address we have for every user is their own private one. We cannot guarantee that all the workers addresses are from Google, so we can't count on Google to keep them logged in. If we had the NGO G-Suite all this would already be solved by having them use the app as themselves logged in the NGO's domain, but that's not the case right now and the new app must be active ASAP.

Do any of you think trying to recognize the device is a bad idea? Why? Alternatives?

I need two things:

1.- To identify WHO is clocking in or out.

2.- To try to make sure no one is cheating when clocking in the name of an other user.

- If I can identify the mobile phone and link it to user1 by the BROWSER "fingerprint" (the browser agent, software version, plugins installed, JavaScript options enabled, etc... NOT a USER recognition device, be it the user actual fingerprint or face) I can make sure THAT phone is not used to clock any other user and half of the pending problem is solved. Then all I have left to do is identify WHO the legit user for the phone is (his ID) and make a table linking IDs with phones.

- The other part is HOW to keep the legit user ID "alive" for the browser so when opening the page in a new tab it knows who the user is. The easiest workaround is to pass it as a parameter to doGet. It may not be elegant at all, but it would be at least effective if I solve the other part and identify the phone legit user.

Thanks for reading! :D 

As I further explain the problem or some of tit's details on each iteration I get a clearer idea of what I really NEED vs what I initially WANTED. ;)

El dia dijous, 7 de gener de 2021 a les 20:47:10 UTC+1, George va escriure:

[cbmserv...@gmail.com]

Jaume,

 

I would not recommend biometrics either. This is not an issue of high security.

 

You do need to protect against cheating, so up to you how you want to implement this. In your first email you indicated it is a GSuite environment, but if not all users have a GSuite account, then you can not expect people to be logged in.

 

Using device signature may be ok as long as you use the right info. If you use too much like software package versions etc, then it will be difficult to maintain as software is updated regularly. If you only use high level info like Chrome/Safari, that may not give you enough info to differentiate the users.

 

Each mobile phone has an IMEI (International Mobile Equipment Identity) number (15 digit) which is unique. The telephone number is also unique. But no browser can get access to that, to allow you to uniquely identify the user of that device. Your only option is to write a native App to be able to read that info.  Read this article for more info:

 

Programmatically obtain the phone number of the Android phone - Stack Overflow

 

Do let us know the results of your investigation as there may be others interested in this and your work would benefit others.

To view this discussion on the web visit https://groups.google.com/d/msgid/google-apps-script-community/2b8bb8a7-70e6-49c3-a826-9e95390725e9n%40googlegroups.com.

[bbau...@gmail.com]

One of the options is to control the Mac addresses of users connected to the Wi-Fi router.

Set the filtering mode for MAC addresses. The client will be able to connect to the device via Wi-Fi if its MAC address is listed in the MAC address list.

When you connect an employee to the Wi-Fi network, fix the Mac address of his phone.

You will be able to log into the router via the web interface and see how many and which users are connected to the Wi-Fi network. This can also be done remotely via the Internet.

It is clear that in this way you will be able to control the presence of phones in the network area, but not people. An employee can leave the phone in the building and go to play golf without a phone, so you can't do without chipping :-)

пятница, 8 января 2021 г. в 06:29:33 UTC+3, George:

[Alan Wells]

By accessing and storing information related to identifying a user,

I'd think that you automatically need to have a Terms of Service and Privacy Policy for your app.

Even if the app is restricted to organizational use for internal purposes,

if the users are using their own personal device, then I'm assuming that you need their consent.

That mean's asking for consent and making an effort to be able to prove that you had their consent.

So, regardless of the technical viable solution to this need,

you might want to have someone ask the users what they think of getting information from their device.

[Jaume Aragay]

If I can get localStorage to work I won't need the browser fingerprint... I've had a different idea that solves it all. No need for TOS and Privacy Policy... There will be no user related data but they can't cheat either... WIN-WIN... I just need localStorage to work... I'll keep you posted! ;)

El dia divendres, 8 de gener de 2021 a les 14:19:08 UTC+1, aj.a...@gmail.com va escriure:

[Jaume Aragay]

Hi! :)

I finally managed to make it work using only localStorage: I have one-time codes assigned to a users list so when I send an email to a user with that code in a link the app looks for the user related to that code and puts some info to identify the user in the localStorage. They can't cheat as they don't have the user code and the other code expires after first use so it links the user to the phone without fetching personal info. If the localStorage is erased, they can ask for a new code with theire email.

Now I'm developing this idea to see if it's solid enough for production environment.

El dia dissabte, 9 de gener de 2021 a les 0:53:46 UTC+1, Jaume Aragay va escriure:

[Alan Wells]

If the strategy works, but you encounter issues related to the Apps Script Web App, will you look at a different service for the app?

[Jaume Aragay]

AJ: I have considered 3 other viable solutions if this one does not work properly that may include external 3rd party elements when needed. From closer to further from GAS, all with a free tier at the basic level:

1.- Google Workspace + Firebase Authentication. (All Google).
2.- Google Workspace + Autocode. (3rd party).
3.- LAMP + Google Desktop API to get clocking data to the proper Sheet. (External "looking into" Google). ;)

If not possible at all, then just LAMP and some library for the  Dashboard.

El dia dilluns, 11 de gener de 2021 a les 14:24:21 UTC+1, aj.a...@gmail.com va escriure: