Good morning, I have a question, you can log in to the glide app, using a personalized username and password, without the need for an email. thanks
If you have a public setup and store a combination of username - password in a Sheet then theoretically I think you can:
-
Have user-specific columns for users to input their username and password
-
Create a template column to join the inputs above.
-
Create a template column in the username - password stored sheet.
-
Create a relation matching the two templates.
If relation is not empty then you allow them to see certain tabs/components, would it work?
However there is big security concern here. Anyone can access your username & password sheet using network resources, so I don’t recommend it.
1 Like
Thanks for the answer, the relationships if I understand them, you could create the user sheet and password, but how do I make the login page?
You make your app public, and have a login tab with two entry components writing to user specific columns for username and password.
As I type this, I’m thinking you should have a logic or a choice component to cover the difference between first time sign up (they have to write their username and password via a form) or login when they have already submitted a username-password combination.
Thanks again, I am looking for the login screen but only the field for mail appears or in case of being pro, password, but it is the same password for all users
You won’t be able to edit that screen, that’s why I said you should make a public app, with a user profiles setup.
[As #ThinnDinh has observed, my comment is not about the original poster’s question, I have decided to move this post to a question/suggestion of it’s own]
I think the confusion on this issue tells me that something is wrong here.
In most apps that I use, if I want to use the app, I need to establish a username and password so that information related just to me can be stored.
I don’t see a simple mechanism that packages all that needs to be done to accomplish this in one or two easy steps. All of the explanations have three or four or more steps to cause glide to do what should be an easy operation.
It seems to me that there ought to be just 2 choices:
- An app requires no login
- An app requires a username and password so that private information associated with a particular user can be stored securely.
What am I missing?
Thanks,
– Harry
1 Like
What the original poster wants is that their app still needs a “workaround” for the login with their own “username” and combine that with a password, hence we must go the public way and use user-specific columns for that.
They don’t want to use emails.
Password are apps no good?
What do you mean, can you clarify more?
What thinh is saying is make the app public to anyone, your home page is the login / register page, it uses visibility features to hide the option to move forward when the data is entered it checks the login name field and password field for a match in the users, also if they are not a user then they click a form button that adds them to the user sheet. So back to logging in when the values are found on the users page it then allows you to move forward by the visility list displaying that user or a button, or whatever you fancy, when clicked t moves the glide app into that row the username resides on and will pull the data from the columns above thta match the current row you are in. Is that what your trying to say Thinh?
Glide does not offer traditional user+password authentication. We will likely offer it someday.
Maybe you can approximate this, but it will not be secure. Please use our pin-based authentication for secure login.
4 Likes
Not to save user passwords in Google Sheets.
That would be a really bad idea. If you wanted to try and implement some form of user/password authentication, at the very least the credentials should be in a Glide table.
But, @david’s advice is best. Just stick with the pin based authentication. It’s simple, secure, and it works.
3 Likes
Just to add to David’s response, a homegrown username and password system is a bad idea because that entire list of usernames and passwords will be downloaded to the user’s device in clear text. Since proper security, like row owners, is not used, then any savvy user will be able to find that complete list of usernames and passwords and be able to sign in as any user. This also puts any user at risk if they happen to use that same password on different websites, bank accounts, email accounts, etc. This could get you into legal trouble if you aren’t careful. I would always recommend using Glide’s built in sign in methods which are secure and encrypted. Or at the very least advise the users that their credentials are not secure and encrypted if you still prefer to build your own username and password process. Also tell them not to reuse a password that they use on another site.
3 Likes
To put it more directly, never store passwords in a spreadsheet.
5 Likes
David,
Can you point me to a Glide app which I can copy to see how it works or some documentation that tells me how to build an authentication system in the existing Glide primitives which allow me to build up an authentication system that allows:
-
Anonymous User: Has access to a limited amount of public information in an app.
-
Logged in User: Can provide a username and password to sign up for a service. Has access to additional access controlled information including information private to the user.
-
Subscribed User: Can provide username and password to submit a subscription that will be further moderated to determine eligibility to use a service. This is like a user signing up for a private email list where the moderator determines if the user can join the list.
I’m happy to use this pattern to create the common kind of access control system seen in many online applications. I am willing to drop the password in favor of a pin sent to the user’s registered email. In effect, Glide will then be relying on the user’s email system to supply user authentication – which although a two-step process, is fine with me.
Thanks.
1 Like
You could actually do this using imported ranges from separate sheets and locking down the second sheet and allowing the glide sheet to import results without compromising anyone’s data. You could even go as far as encrypting the second google sheet to add additional security.
Jeff,
Harry stands on soapbox:
This is why I originally asked “why there is not a username/password mechanism implemented [securely] in Glide” so that the standard way most non-programmers already understand is easily available and properly implemented.
Implementing the standard stuff people understand is the only way one of Glide’s goals (“billions of programmers in 10 years”) is going to be achieved. Implementing these commonly understood mechanisms as high-level constructs is the key to achieving these goals. In some sense, this is analogous to the way almost all developers of mass-market document editors have adopted WYSIWYG as the way to get beyond arcane text markup strategies, and developers of spreadsheets have made it possible for business people to go beyond ledger sheets and calculators. In Glide’s case, the activity being improved upon is the creation of smartphone apps.
Of course, programming all of the needed high-level constructs is a big job, but the payoff is making it possible for normal people to be as creative as us programmer-developers. I applaud what has already been accomplished in Glide to move up levels in programming – doing for building apps what spreadsheets did for numerical calculations. This is hard to do for many reasons including overcoming the ways programmers think about a problem – “I can always program up a solution”. Abstracting up by combining the many “atoms” of programming needed to create the new “molecules” of a higher abstraction is hard work.
I want Glide to provide as many high-level constructs as we can think are needed by normal people to create new apps – high-level constructs such as data organized in rows of cells of different named properties (done in Glide by use of Google spreadsheets to hold all data of an app), automatic recognition links from an item in one row of a spreadsheet to another row in (possibly) another spreadsheet (done in the Glide relation which came from relational databases). And, a high level construct which implements username/password authentication and access control (not done). The security mechanisms we have now are all valid for certain use-cases of security and access control apps. A high-level username/password construct would fill out the set of such security/access control mechanisms in Glide.
Harry steps off soapbox;
Regards,
– Harry
3 Likes