Recent Posts
Where to apply
Ea+JT0
No.1380
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.
Ea+JT0
No.1381
>>1380(OP)
Yes it will be free.
ifttQj
No.1382
>>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.
Ea+JT0
No.1385
>>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.
ifttQj
No.1387
>>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.
Ea+JT0
No.1389
>>1387
but anyone can see that token. Making user create a server to store token safely defeat the prpose
ifttQj
No.1391
>>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.
V5/BGm
No.1405
bump
V5/BGm
No.1406
>>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?
V5/BGm
No.1407
Won't be continuing with this as there isn't any scope and scale in it.
9UQNNl
No.1408
>>1380(OP)
already exists lol
bazillion companies do this, see cloudflare d1 and yes there's many alternatives
+JvOvC
No.1409
>>1385
>I don't want him to use a server. Directly call the service from frontend.
you don't want to put anything in the database directly
never trust the users
you have to check if the data is correct and do a sanity check before performing a database operation
V5/BGm
No.1410
>>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.
XJs3H5
No.1556
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
mmToFH
No.1623
Backend done.
Frontend will be done by noon probably.
Will buy domain , vps and setup tomorrow
DJlCrE
No.1624
>>1380(OP)
Bharattube admin doing weird shit now
W0s0RD
No.1625
>>1624
kek
