At a minimum, this should be password protected by default.
One of the security lessons from the late 1990s and early 2000s is that things like this quickly get hacked. Many developers forget that a service where all security is handled client-side are easy targets for hacking.
Furthermore: In a lot of cases, people will ship prototypes and run their stuff on top of them long after they have outgrown a critical component.
I have tried to write a universal backend... It's possible, but you really have to work in a permissions model from the beginning. What you'll find is that basic read/write/own enables very basic functionality. Unfortunately, to do anything complicated, you will need to write server-side queries that verify that the user is allowed to do what they are trying to do.
A very basic REST service for JSON data - enough for prototyping and MVPs!
Features:
no need to set up a database, all data is managed automagically*
REST paradigm CRUD for multiple entities/namespaces
schema validation
search using jq like syntax
CORS enabled
easy to deploy as container
>>Now that it's been posted to HN you might see malicious actors.
This needs to be an HN fN Masterclass by @Dang....
We should have regular visibility into /how/ HN is used by malicious actors.... HN has enough pedigree to get some insight from some of the top security folks... and it would be REALLY good to know how HN is being harvested in this space.
currently there are two implementation for the database "behind": in memory or with postgres, both with zero config (except for starting an instance of postgres, in the second case!).
it can be easily extended to use files as persistence, good idea :)
regarding the pre-population, you can just make a quick script with curl that will add some data after you run the service. any thought?
FYI, there is a name clash with Caffeine, a Mac OS menu bar app that keeps the screen awake: https://intelliscapesolutions.com/apps/caffeine . But I guess this is expected with a name like this, and the scopes of the projects are clearly different, so this should be relatively harmless.
Hah! I'm not sure my MVP has ever had error handling beyond "Something went wrong.". That's something for a real production app, not the minimum possible product.
I realize this is just for prototyping but it looks like it just spits sprintf SQL strings into the database.
While not a security risk if done locally, why not just use a where string builder to generate the $ values and a variadic as the input? It's about the same amount of work.
I could have used something similar recently, but that persisted to disk as json. I ended up just storing a wad of JSON on disk and memory, loading and saving as needed. Will only ever be 1M or so and only 2 users.
Readit News
One of the security lessons from the late 1990s and early 2000s is that things like this quickly get hacked. Many developers forget that a service where all security is handled client-side are easy targets for hacking.
Furthermore: In a lot of cases, people will ship prototypes and run their stuff on top of them long after they have outgrown a critical component.
I have tried to write a universal backend... It's possible, but you really have to work in a permissions model from the beginning. What you'll find is that basic read/write/own enables very basic functionality. Unfortunately, to do anything complicated, you will need to write server-side queries that verify that the user is allowed to do what they are trying to do.
As soon as you involve auth, things get boring and annoying.
No, JWT is easy enough to implement.
Features:
I also think it's prone to SQL injection at the moment? At least, it's raising a syntax error when inputting an apostrophe.
https://github.com/rehacktive/caffeine/blob/master/database/...
"INSERT INTO %v (id, data) VALUES('%v','%v') ON CONFLICT (id) DO UPDATE SET data = '%v'"
Use prepared statements and parameters passed to the db driver, not building strings with strings or you are vulnerable to sqli.
I'd also avoid using %v anyway when building strings - safer to use a specific type like %d for int.
This needs to be an HN fN Masterclass by @Dang....
We should have regular visibility into /how/ HN is used by malicious actors.... HN has enough pedigree to get some insight from some of the top security folks... and it would be REALLY good to know how HN is being harvested in this space.
Dead Comment
Taking it even further; how about persisting the data in the file?
Sometimes your prototype will need some pre-added data so I think this might be useful.
http://wiremock.org/
It's more complex than Caffeine, but it has a lot of options.
It can also run as a proxy and generate the mocks from actual http requests passing through the proxy
regarding the pre-population, you can just make a quick script with curl that will add some data after you run the service. any thought?
Deleted Comment
Jokes aside… chaos engineering is a big deal right now - this isn’t a terrible idea and might be worthy of a fork.
While not a security risk if done locally, why not just use a where string builder to generate the $ values and a variadic as the input? It's about the same amount of work.