Login options

I have an app I created for an experience. This experience is one time corporate training experience for 6-15 users, so I could never afford the per user AppSheet rate to buy a license for every person who does our workshop. So I created 15 google email addresses with different email and password logins and then I bought 15 AppSheet licenses and I basically rotate our one-time participants through these 15 emails and licenses. However, we are constantly having problems with google and peopleโ€™s phones. Either they already have a google account and have to either add this account or logout of their existing account. We have problems with googleโ€™s security blocking them from the account and requiring them to have a code sent to them. Itโ€™s been a nightmare for our users who we want to download the app before the experience. We spend much of the workshop getting certain users to be able to finally login to the app. I donโ€™t know if there is another way to accomplish what Iโ€™m doing. I know itโ€™s not traditional to how AppSheet is used. Is there a way to create 15 Microsoft emails? Is that a solution? Is there any other sign in accounts that make more sense (i.e.- box, Dropbox, etc)

0 8 458
8 REPLIES 8

Steve
Platinum 4
Platinum 4

I encourage you to contact sales@appsheet.com.

Silly question, do you have to be 100% certain of the users or are you simply trying to keep their progress and actions separate from each other? If you are directly working with the users and verification is not the utmost then a public app with a User ID number that you can just email them and having them enter into their user settings when they log in could be a solution. You will run into different problems with this approach but those might be better then your current problems.

Thanks Austin for the thoughts here. I guess Iโ€™ll have to try it. I was thinking of using the machineid to replace the useremail (which is what Iโ€™m using throughout the entire app to give a user their own view) and make it public. And yet it will be a ton of work to replace everywhere I have useremail in the app. Iโ€™m up for it, but Iโ€™d love to know what are the โ€œdifferent problemsโ€ that Iโ€™ll run into? Itโ€™s a dynamic app and not a static one for the user, so Iโ€™ve alway been afraid that the public app is just static.

No, you can have a public app that is dynamic to the user. You just lose any way of verifying that the user is who they say they are like authenticating through a google login. Some other problems are that users will maintain access to the app page itself even after you remove their โ€œuserโ€. As well anyone with the URL can open the app and possibly get any data that the app has access to, according to one of their articles but I am not able to find that nor was I able to access all the data the app had access to but that stuff is not my specialty.

Correct!

But if I make it so the machineid replaces the useremail and only give a user a view based on their machine idโ€ฆdoesnโ€™t that keep them from accessing others info.

Not necessarily. The article has vague language which is probably for the best but it makes it sound like even without knowing a valid user someone could retrieve the data.

I found the article!

Can I secure an app without making users sign-in?

section 2 is the specific part I am referring to

Good stuff, thank you

Top Labels in this Space