JSONbin.io – Simple JSON Storage (Beta)(jsonbin.io)
jsonbin.io
JSONbin.io – Simple JSON Storage (Beta)
https://jsonbin.io/
50 comments
Hey, thanks, yes, I'll be releasing these fixes by tonight.
Really sleek and clean, love the design. A simple but useful product, nice job :)
The link to your Twitter on the about page is broken by the way, it should have a protocol.
The link to your Twitter on the about page is broken by the way, it should have a protocol.
Thanks a lot :)
P.S Twitter link is now fixed.
Minor bug: The Access URL it generates is invalid. E.g. copying "//jsonbin.io/b/591a7e1cc94cae11ebb443dc" into Chrome's URL bar results in attempting to navigate to "file://jsonbin.io/b/591a7e1cc94cae11ebb443dc", not jsonbin.io/b/591a851ac94cae11ebb4440e.
Hey, thanks, but it's not a bug :) that's protocol independent URL, it works on HTTP, HTTPS, relative to what your website is running on.
The primary purpose of your app is to paste some JSON then send someone a URL to access it, right?
If a user pastes some JSON, clicks the Access URL text box, presses Command-A Command-C to copy the URL, then pastes it to someone else, that person won't be able to open the URL, because it lacks a "https: prefix. That's probably a bug, whether or not it's an intended feature.
It's not something that matters very much, but your users might be slightly annoyed at having to chop off the leading "//" every time they want to copy the URL.
I admit I might be missing something obvious, though.
If a user pastes some JSON, clicks the Access URL text box, presses Command-A Command-C to copy the URL, then pastes it to someone else, that person won't be able to open the URL, because it lacks a "https: prefix. That's probably a bug, whether or not it's an intended feature.
It's not something that matters very much, but your users might be slightly annoyed at having to chop off the leading "//" every time they want to copy the URL.
I admit I might be missing something obvious, though.
The primary purpose of the app is to provide free storage and an endpoint to access it in an app. I've also provided a VIEW link beneath the access URL to view it in the browser. If I hard code https:// in front of the access URL, it might fail on non-https URLs and vice versa. Still, I think your concern is legit, will look into it and try to make it more flexible. Thanks for the suggestion bud. Appreciated.
Ah, got it. Nah, you're right, it's obviously meant to be used from within apps, not manually sent to someone else. Just a late-night derp.
I didn't expect it to be a service for freely hosting data -- that's pretty cool. I assumed it would return a rate limit error if you tried to use it for anything substantial.
(I missed the About link https://jsonbin.io/about at the bottom, which explains all this.)
I didn't expect it to be a service for freely hosting data -- that's pretty cool. I assumed it would return a rate limit error if you tried to use it for anything substantial.
(I missed the About link https://jsonbin.io/about at the bottom, which explains all this.)
Yeah it also struck me as something weird and I know about using //. Maybe prepend http/https based on the current page's protocol? So that URL looks like a URL.
By the way cool service. I've got an internal JSON store service too and it's super useful for a number of purposes.
By the way cool service. I've got an internal JSON store service too and it's super useful for a number of purposes.
it's perfectly okay to load https content on the http urls, just not vice versa
Wait. So this just stores arbitrary byte blobs right. What exactly is the JSON bit about? Can I use jq syntax to query and transform whatever JSON is stored?
You can transform whatever you want once you request for the stored JSON
I made the exact same thing couple of years back, but shut it down because I couldn't think of sustainably maintaining such a "free" service.
I have a lot of ideas like this, but I am super confused on the sustainability part. What ways are there to sustainably maintain such services?
I have a lot of ideas like this, but I am super confused on the sustainability part. What ways are there to sustainably maintain such services?
On another note,
Why the 'snippet' additional step when creating new fiddles?
Being able to do:
curl -X POST -d @test.json https://jsonbin.io/b/new
will be cool!
Why the 'snippet' additional step when creating new fiddles?
Being able to do:
curl -X POST -d @test.json https://jsonbin.io/b/new
will be cool!
I thought that's how it works?
https://jsonbin.io/api-reference
https://jsonbin.io/api-reference
$ cat test.json
{}
$ curl -X POST -H "Content-Type: application/json" -d @test.json https://jsonbin.io/b/new
{"success":false,"message":"Snippet parameter is missing"}
$ echo '{"snippet": "{}"}' > test.json
$ curl -X POST -H "Content-Type: application/json" -d @test.json https://jsonbin.io/b/new
{"success":true,"data":"{}","id":"..."}
{}
$ curl -X POST -H "Content-Type: application/json" -d @test.json https://jsonbin.io/b/new
{"success":false,"message":"Snippet parameter is missing"}
$ echo '{"snippet": "{}"}' > test.json
$ curl -X POST -H "Content-Type: application/json" -d @test.json https://jsonbin.io/b/new
{"success":true,"data":"{}","id":"..."}
Oh, you're right. My bad. Maybe they want to leave room for meta data in the future or something.
Cool. I really like the UI. Response times are slow-er than I would have originally thunk, but I'm sure that's a side effect of the HN hug.
Are you saving these "bins" as files, and then serving them? Or are you putting them into a database? Mostly curious. :)
Are you saving these "bins" as files, and then serving them? Or are you putting them into a database? Mostly curious. :)
Thank you :) yea, kinda overwhelmed right now with the traffic, should sort out once the dust settles down. As far as your question goes, I don't store them as files, they are in DB. The file is fine for a temporary run, not great when it comes to scaling.
Why not host them on S3? You can probably serve them directly from there too.
But the URL would not be that pretty, would it?
Why not? You can assign a domain to S3 buckets. It can be just as pretty as it is today. The only difference is if he serves them directly from S3, the domain will be different from the creation API.
But considering the additional features he's planning on adding, he will probably need to proxy S3 anyway, so not sure if it's worth it in this case.
But for something of the scope of the current API, S3 is the perfect solution.
But considering the additional features he's planning on adding, he will probably need to proxy S3 anyway, so not sure if it's worth it in this case.
But for something of the scope of the current API, S3 is the perfect solution.
you could set up an nginx proxy in front of it, or use the S3 static website feature with custom domain
For a similar service which is entirely encrypted, consider: https://safepaste.org/
Your content is being sent to the server encrypted, but it gives you a URL which decrypts it on demand. TLS already does this, right?
Relying on this is a very bad idea. The server could be logging everything and you'd never know. Heck, the server could be imaged at wherever it's hosted and you'd never know. The "burn after reading" feature is impossible to verify. It's just another "Take our word it's doing this" service.
If the website can spit out out a URL that you're then able to view your unencrypted data in, that website is no more secure than pastebin.com. And at least pastebin.com is explicit that everything is logged.
Relying on this is a very bad idea. The server could be logging everything and you'd never know. Heck, the server could be imaged at wherever it's hosted and you'd never know. The "burn after reading" feature is impossible to verify. It's just another "Take our word it's doing this" service.
If the website can spit out out a URL that you're then able to view your unencrypted data in, that website is no more secure than pastebin.com. And at least pastebin.com is explicit that everything is logged.
> Your content is being sent to the server encrypted, but it gives you a URL which decrypts it on demand. TLS already does this, right?
No, since TLS doesn't have anything to do with the original content being encrypted, such that the server can't read it. safepaste should combine TLS with this client-side encryption/decryption (as the hosted version does).
> Relying on this is a very bad idea...
Considering it's FLOSS, I don't think any of those points are valid. I agree that, for it to be more trusted, it should be self-hosted. So, self-host it! Verify it's not logging! Verify the "burn after reading" does the deletion! If you care at all about security, and hosting a secure service, that's going to be essential anyway.
Boiling down the FLOSS project to its provided hosted version is quite missing the point.
> If the website can spit out out a URL that you're then able to view your unencrypted data in, that website is no more secure than pastebin.com.
Given that the encryption/decryption happens entirely on the client side, this simply does not apply. The server knows the paste id, not the secret key. That's kind of the whole point. :)
- Edited for clarification
No, since TLS doesn't have anything to do with the original content being encrypted, such that the server can't read it. safepaste should combine TLS with this client-side encryption/decryption (as the hosted version does).
> Relying on this is a very bad idea...
Considering it's FLOSS, I don't think any of those points are valid. I agree that, for it to be more trusted, it should be self-hosted. So, self-host it! Verify it's not logging! Verify the "burn after reading" does the deletion! If you care at all about security, and hosting a secure service, that's going to be essential anyway.
Boiling down the FLOSS project to its provided hosted version is quite missing the point.
> If the website can spit out out a URL that you're then able to view your unencrypted data in, that website is no more secure than pastebin.com.
Given that the encryption/decryption happens entirely on the client side, this simply does not apply. The server knows the paste id, not the secret key. That's kind of the whole point. :)
- Edited for clarification
The server gives you a URL like https://safepaste.org/10dab736#595f4642d2fbcf14a235a9de40a37.... When you load it, the end result is that you're viewing your decrypted data. That means the server can also load the URL (which it generated for you originally, and therefore knows) and decrypt the data. What am I missing?
Considering it's FLOSS, I don't think any of those points are valid. I agree that, for it to be more trusted, it should be self-hosted. So, self-host it! Verify it's not logging! Verify the "burn after reading" does the deletion! If you care at all about security, and hosting a secure service, that's going to be essential anyway. Boiling down the FLOSS project to its provided hosted version is quite missing the point.
This isn't valid. The fact is, this service isn't self-hosted and is encouraging people to use the non-self-hosted version. There is no guarantee that the code running on the server is identical to the github repo.
Considering it's FLOSS, I don't think any of those points are valid. I agree that, for it to be more trusted, it should be self-hosted. So, self-host it! Verify it's not logging! Verify the "burn after reading" does the deletion! If you care at all about security, and hosting a secure service, that's going to be essential anyway. Boiling down the FLOSS project to its provided hosted version is quite missing the point.
This isn't valid. The fact is, this service isn't self-hosted and is encouraging people to use the non-self-hosted version. There is no guarantee that the code running on the server is identical to the github repo.
> What am I missing?
The key part; the secret key is never sent to the server. http://stackoverflow.com/questions/14462218/is-the-url-fragm...
This was explained in safepaste's about page:
-- The hash section of the URL, after the #, is never sent to the server; it's used only by the browser and safepaste takes advantage of that to store the secret key. --
Thus, the server cannot know the contents of the paste, since all encrypting/decrypting is done client-side. It's just a blob store for encrypted data.
> There is no guarantee that the code running on the server is identical to the github repo.
Agreed. That's why the whole paragraph you just quoted said you should run your own copy and verify it does what you want. That doesn't mean you should run your own for everyone else, it means you should run your own for you and those who trust you.
The key part; the secret key is never sent to the server. http://stackoverflow.com/questions/14462218/is-the-url-fragm...
This was explained in safepaste's about page:
-- The hash section of the URL, after the #, is never sent to the server; it's used only by the browser and safepaste takes advantage of that to store the secret key. --
Thus, the server cannot know the contents of the paste, since all encrypting/decrypting is done client-side. It's just a blob store for encrypted data.
> There is no guarantee that the code running on the server is identical to the github repo.
Agreed. That's why the whole paragraph you just quoted said you should run your own copy and verify it does what you want. That doesn't mean you should run your own for everyone else, it means you should run your own for you and those who trust you.
Ah, thanks for clarifying. I retract my comments.
Hi, very cool, simple service! I believe the example on the front page, should be Linkin Park without the "g".
Hey, thanks a lot :D
P.S Fixed the typo x)
P.S Fixed the typo x)
Nice!, Also when I click on Twitter link on the about page it sends me to a bad URL. Looks like you just need to add http in front of the link.
When I copy and paste the access URL I see it starts with // - so the link doesn't go anywhere, is that the intended action?
When I copy and paste the access URL I see it starts with // - so the link doesn't go anywhere, is that the intended action?
Thanks for the check again, much appreciated :) .. twitter link is fixed.
About the access URL, // is intentional as it's protocol independent. You can use either http or https, depends on your app page :)
I might make it all https once I sort out my nginx config :)
Thanks again for helping me out bud.
About the access URL, // is intentional as it's protocol independent. You can use either http or https, depends on your app page :)
I might make it all https once I sort out my nginx config :)
Thanks again for helping me out bud.
Your welcome, thanks for the explanation on the protocol independent link.
This type of post inspires me to continue working on my side projects / learning new things!
This type of post inspires me to continue working on my side projects / learning new things!
Why is this better then just storing json files on s3?
This has a simpler copy-paste usage. And plus, JSONbin.io is a free service.
would be nice if the user can set the url
sth like this
jsonbin.io/username/books/get/1
sth like this
jsonbin.io/username/books/get/1
Hey, thanks for the suggestion. I have that on my roadmap once I implement authentication. Later, one can create private bins, version control for the same, query only specific data out of your entire JSON and so on. Feel free to throw in if you have any more suggestions. :)
"Entity" in "Unprocessable Entity" refers to request body and for GETs there is no request body: http://www.restpatterns.org/HTTP_Status_Codes/422_-_Unproces...