Best patterns for authentication for Glitch apps?

Glitch Help
1

I’d like to build a Glitch app with authentication - so the owner of the app can “sign into” it before using it - and allow other users to sign in too.

I want to do this in an app that is designed to be remixed - so anyone can click “remix” and get their own private copy that they can sign into.

What are some good patterns for doing this? Has anyone seen examples of this kind of app in the wild?

2

It seems to me like the “secrets” feature is the right way to go here - so one option could be to tell people “create secrets called USERNAME and PASSWORD and then use those to sign in” - but that might be a bit fiddly for people so I’m interested in exploring other options if they exist.

3

It would be unwise to use the .env files for storing sign-in data such as usernames and passwords for multiple reasons, including project storage and it’s accessibility. Also, .env files are used for storing project secrets related to the project.

Glitch has a persistent file system, so anything you store within your project is kept even after your container sleeps. This means you can use files as a flat-file database, save your database files locally, or use third-party storage services like a hosted MongoDB database or Redis. Glitch also supports the usage of SQLite and MySQL. Here are some more ways to store data and fetch them: https://glitch.com/@storage

4

Maybe not best patterns, but some ideas …

User, Password

Rather than store the password, store a cryptographic hash of the password.

I’d also encrypt the table of user/hashes before storing, and have the decryption key in .env, because Glitch project storage is generally shared with remixes and invites (except .data and other files in gitignore).

Email + One-Time Password (OTP)

An implementation of this is at Free Code Camp. To login you type your email address, it sends an email with a generated code that is to be input on the login page.

Auth0

Use a third party service to login via your facebook, gmail, github, etc account. The app decides what other info it wants, and the user is shown these permissions before accepting.

Edit thanks for the correction @WilsontheWolf

1 Like
5

Just out of interest, how do you do this?

6

Good question!

I think the email part would need:

  • External email service
  • Custom domain name
  • MX and SPF config so the email isn’t rejected as spam

The OTP part could be done many ways, I would use:

  • server secret in .env
  • email address
  • current timestamp
  • Node’s crypto built-in package
  • One of the hash digest algorithms such as Hmac256
  • Convert the digest to something easier to type in
  • In-project storage for the email address + hash digest
  • Can remove OTP from storage after used or expired
1 Like
7

Storing salted and hashed passwords in the .data directory sounds smart, but what I’m missing is the cleanest way to bootstrap that system for a user who has just clicked the “remix” button.

Do I need to talk them through hitting “remix” and then opening up the web-based command-line console and running a command to set up their user account?

Is there a nicer user experience I can provide here for setting up that initial authentication method after remixing my project?

8

if u git ignore something like a /data folder it wont show up in the edior and wont be copied on remix. the app still can acess it. If u want to make it where users can remix just have it make the file(s) when not found