Trouble creating login with multiple values

[samcho]

Hi! I am fairly new to MIT App Inventor and I am trying to create a login for a sports app. I figured out how to login with email and password with Google sheets, but I have a separate sheet for the user type: Coach, Player, or Parent. I also want to have the login screen find what type the user is, but I do not know how to code it. This is the .aia
HomeBase_copy (1).aia (248.7 KB)

And these are the code going wrong.

Please let me know if you need anything else to help! Anything would be appreciated.

[samcho]

I'm guessing the "List from csv table" is the problem because there are 2 but nothing to differentiate them but I'm not sure.

[Taifun]

@samcho

but I have a separate sheet for the user type: Coach, Player, or Parent

What about having only one sheet with the columns email, password and userType?

After login button click you could use gviz to send a query to the table like this
.select b, c where a = entered email address.

Use gviz to get and query google sheet data

[gvizscreen1] Guide on how to use the google visualization API to get and query "public" google sheet data Use gviz to get and query google sheet data Note: this approach has been knocking around for years, e.g. https://puravidaapps.com/spreadsheet.php, but I have never seen it "properly" explained like this...

Also please do not store passwords in plain text in an online database, store password hashes instead to keep your users' data save

To store password hashes is very simple, the tools extension offers a method for that App Inventor Extensions: Tools | Pura Vida Apps

And later if you want to check, if the entered password is correct, compare the password hashes

What is a hashed password? | 1Password

I now asked Gemini

Is it okay du store passwords in plain text in an online database?

Here is the answer

Storing passwords in plain text in an online database is extremely dangerous and should absolutely be avoided. Here's why:

• Major Security Risk:
  • If a database is breached, all passwords are immediately exposed. This puts every user at significant risk of identity theft, financial loss, and other harmful consequences.
• Violation of Security Best Practices:
  • Security professionals universally condemn storing passwords in plain text. It's considered a fundamental security flaw.
• Legal and Regulatory Issues:
  • Many data privacy laws and regulations (like GDPR) require organizations to protect sensitive data, including passwords. Storing them in plain text can lead to legal penalties.
• Damage to Reputation:
  • If a company's database is breached and passwords are leaked, it can severely damage the company's reputation and erode customer trust.

Instead of plain text, passwords should be:

• Hashed:
  • Passwords should be transformed using a one-way cryptographic hash function. This makes it virtually impossible to recover the original password from the hashed version.
• Salted:
  • A unique, random string (a "salt") should be added to each password before hashing. This prevents attackers from using pre-computed "rainbow tables" to crack passwords.

In summary, storing passwords in plain text is a highly irresponsible and dangerous practice. Secure hashing and salting are essential for protecting user data.

Taifun