/g/ - Technology

Anyone interested in Database as a Service.

Like you don't need to create a server and db. Just use my website and with one click create a table. You will get a link where you can GET/POST/DELETE the data in table. You will just have to create a frontend and call the API from there. Thats it , no backend chikcik.

But I'm stuck at one thing. How would I prevent spam. As the links can be seen through network tab , anyone can make request to them.

Chatgpt was not helpful. Anyone can brainstorm on this , would be great.

>>1380(OP)

Yes it will be free.

>>1380(OP)

Kinda like firebase?

>how would i prevent spam

Duh have separate user management? Subscription system. Based on that they get access to your db resource where they can allocate or de-allocate.

Some small startups or businesses may like your idea in fact most small businesses will prefer your service if it's easy to store data etc. Enough for you to work out your project.

>>1382

No. You didn't understand.

User will create a table and get a URL https://abc.com/table. He will POST {name :gay}.

I don't want him to use a server. Directly call the service from frontend.

BUT

then anyone can check the link and make the request , spamming the table.

...

Auth is not possible because the auth keys will still be visible in request body.

Checking origin will be a problem too as spammer can spoof it with curl.

...

Need a noval solution.

>>1385

hmmm, it's good idea that when you generate a table you should have some sort of token for authentication.

that token ca be part of the url as a parameter or a query depending on your choice.

>>1387

but anyone can see that token. Making user create a server to store token safely defeat the prpose

>>1389

well why would one want to expose the db details to the public?

He can create a wrapper or api or whatever for his own case. He is supposed to handle those details at the backend not in the front end in the first place.

Obviously your target user is not the final user, he is the one who is providing service to another party through his own API wrappers.

bump

>>1405

deepthi k gave me a good answe

Direct Chat

deepseek-v3-0324

deepseek-v3-0324

I understand your challenge now. You want to provide a simple, serverless database-as-a-service where users can create tables and interact with them directly from their frontend, but you need to prevent abuse/spam without requiring traditional authentication (since keys would be exposed in the frontend).

Here are some novel approaches to mitigate spam:

1. Rate Limiting by IP + Browser Fingerprinting

Combine IP-based rate limiting with browser fingerprinting (using libraries like fingerprintjs).

Even if someone sees the URL, they won't easily spoof the same fingerprint from another machine.

Downside: Advanced attackers can bypass this.

2. One-Time Tokens (OTT) for Write Operations

When a user creates a table, generate a one-time token (OTT) for write operations (POST/DELETE).

The token is valid only for a short time or a single request.

The frontend must request a new token for each write (via a hidden iframe or background fetch).

Spammers can't reuse tokens, and tokens expire quickly.

3. Proof-of-Work (PoW) for Requests

Require clients to solve a small computational challenge (e.g., hash collision) before processing a request.

This slows down spammers but is negligible for legitimate users.

Example: Include a nonce in the request that must meet a certain difficulty target.

4. Invisible CAPTCHA / Behavioral Analysis

Use lightweight, invisible CAPTCHAs (e.g., Cloudflare Turnstile) or analyze user behavior (mouse movements, click patterns) to distinguish humans from bots.

Only allow requests that pass the check.

5. Domain Locking (Optional)

Let users optionally "lock" their table to a specific domain (e.g., example.com).

Verify the Origin or Referer header. While these can be spoofed, it raises the bar for casual abuse.

Combine with other methods for better security.

6. Temporary Write Permissions

Allow writes only for a short time after the table is created (e.g., 1 hour).

After that, the user must "renew" write access manually (e.g., by clicking a button on your site).

7. Frontend-Only HMAC Signing

Generate a short-lived HMAC key for the user's session (stored in localStorage).

Require all requests to be signed with this key.

The key rotates frequently, and spammers can't easily extract it (though determined attackers can).

8. User Approval for Public Tables

If a table is accessed from an unexpected IP/device, require the owner to approve the request via email or a dashboard.

Hybrid Approach (Recommended):

Combine several of these methods, such as:

Rate limiting + browser fingerprinting for basic protection.

Optional domain locking for users who want stricter control.

Proof-of-work for high-traffic tables.

This way, you balance usability and spam resistance without forcing users to manage auth keys.

Would any of these work for your use case?

Won't be continuing with this as there isn't any scope and scale in it.

>>1380(OP)

already exists lol

bazillion companies do this, see cloudflare d1 and yes there's many alternatives

>>1408

Nope. Try to understand. Others are giving access to DB using API. You NEED a backend to access DB from those api.

...

What I'm suggesting is , I GIVE THEM DIRECT API , not backed , a direct link where they send what to put in table or what to get from table. No need of backend.

>>1409

Yes. I don't think it will work well anyway. Maybe as testing ground for devs. But except that any serious site would not use it as auth and spam is a problem.

Im feeling like working on this but at a smaller scope. User selects table name and all fields and their data type. Then he gets a Create , Read , Update , Delete links. Will think about it more and start

Backend done.

Frontend will be done by noon probably.

Will buy domain , vps and setup tomorrow

>>1380(OP)

Bharattube admin doing weird shit now

>>1624

kek