Stop creating Replit DB proxies NOW!

General
1

PLEASE STOP USING DATABASE PROXIES!!!

Okay so recently some of our members have found out about “database proxies”. They let you share a database among multiple Repls. Now, I just wanted the title to catch your attention, but they’re actually fine to make. Here’s how to make one:

  1. Fork https://replit.com/@util/Replit-Database-proxy?v=1
  2. Copy the URL of the Repl (https://replit-database-proxy.(username).repl.co)
  3. Paste it as a Secret in your other Repls.
  4. Use this code
from replit import db

db.url = os.environ["DB_URL"]

Ah, but wait! This Repl doesn’t have a webview, and because of Ghost forks [1] all Secrets’ values are lost when ran from the cover page.

Okay, well, how about we just don’t use a secret?

from replit import db

db.url = "https://replit-database-proxy.(username).repl.co"

Ah, there. Easy peasy! Except, wait, why are there all these random keys in my DB? Wh-what’s going on?

So we’ve gotten to the why. And this, this is why no one should use DB proxies on non-webview Repls.

So why not?

Well, haven’t I told you why? People get access to your DB. And, for now, there is nothing we can do about it.

So thanks for reading.

  1. A “ghost fork” is when you run a (non-website) Repl you don’t own from the cover page and Replit automatically forks the Repl.

    And when a Repl is forked by a user who doesn’t have edit permissions, the Secrets’ values get deleted. ↩︎

6 Likes
2

At this point, it may be easier not easier, but way more affective to just set up some API (attached with ReplitDB or another database) with user-generated API keys to safely authenticate, and it would allow non-web view Repls to easily connect with some database. Simply have each user generate their own API key after forking the Repl, store it in a secret, and it should be good to go.

This is a rediculous amount of trouble for seemingly such a simple task, I wish the process was simpler, intuitive, and more secure.

4 Likes
3

yes, thats when auth and all of the client-server model starts to kick in, where the database proxy is not just a database proxy, but a whole entire logic and auth server

2 Likes
4

You see…

import os

api_key = os.environ["DB API KEY"]

So API keys don’t even solve the problem!

2 Likes
5

I wrote something something of the likes in another topic:

1 Like
6

Yeah, I guess that’s true (for ghost forks)

A user would need to fork the Repl and generate a valid API key your system provides to use the service. Super annoying, but it should work?

2 Likes
7

even auth wouldn’t solve the problem, and sooner or later, the ghost fork becomes the “website”, the repl is the “browser”, and the db_proxy becomes the “webserver”. You might as well create a website to mitigate wakeup times.

2 Likes
8

I know, but I couldn’t find it after a few searches.

We can’t just hand out API keys to every user. They could literally just delete the entire DB…

9

ahem… It’s… Linked… In… The… Post…

10

Yeah I just realized that :laughing:, way more trouble than its worth, but could the server check what sort of requests were being made before changes to the DB were made?

11

well, that would mean adding auth, ratelimits, and basically recreating stuff like replit’s connect.sid and GraphQL

1 Like
12

Yeah, I meant that I knew that before creating the topic, I just couldn’t find it so posted the topic anyway.

BTW @bobastley the proxy would have to be private or something, it is just so hard to make it secure…

1 Like
13

edit: i think i worded it badly so ima try again

Replit should provide a database that syncs with users’ ghost Repls and the official Repl so we wouldn’t have to create this ourselves.

1 Like
14

well, each ghost-fork has a database, but it doesn’t get synced with other users.

2 Likes
15

Don’t say it like they can’t.

16

image

You worded the post as if they couldn’t

2 Likes
17

I realized it was a bit unclear, edited it :laughing:

1 Like
18

For Idkwhttph’s “Train the chatbot” project, I’d recommend making the db proxy read-only, while making another project which directly access the db {doesn’t work when people ghost-fork}. Whenever someone adds a new suggestion/response to the db, you should add auth and/or use a web auth service similar to github CLI auth, where you enter a code into a website. Now, once you have proved your identity with the auth provider (the attester returns a signed id key with the user’s username and a randomized UUID), the db server takes that key, verifies the signature, and does ratelimits/operations accordingly. WIth this, all of my rick rolls would contain my “signature” (info provided by @python660) and making it so that only an admin can delete stuff.

2 Likes
19

What if the Repl behaved differently depending on whether it was a ghost fork or not? Like using a DB if it can access the os.environ secret, but using a local file instead if it cannot? We could further this program by having it synchronize the two when the os.environ secret does exist (when the Repl’s owner/editors access it). This isn’t perfect and would not be secret, but it would do something.

20

what do you mean by this?