So I see this as similar to having a sandbox built into your docs page. Except I can customize a request and send it directly to a user. The only missing piece is the authentication part. Since I wouldn't want to embed an api key in this link.
I kept finding myself sending curl requests in Slack or email, and it felt clunky—especially when non-devs or support teams needed to test something quickly. uncurl.dev started as a way to make that share-and-execute process more visual and frictionless.
For the auth part—embedding API keys in payload is a no-go in most cases. For now, sending out auth headers separately for them to fill in themselves is what I did within my workplace.
I'm exploring a couple of ideas to help with this:
Team-scoped secrets: For logged-in users or teams, saving common auth headers that aren’t part of the shared link.
One-time, encrypted secrets: The link works once and destroys the sensitive payload after execution.
I also think it's weird to be so willing to let people run arbitrary CURL commands from your platform, without any billing or account verification. It feels ripe for abuse.
[0]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/COR...
CORS was a blocker for client side requests, I have a separate branch where this is integrated, maybe will add it alongside server side execution to let the person creating the curl decide whether they can execute on browser or server side.
Really appreciate you taking the time to look and let me know (even if it had to be in public). I have added a github repo for filing bugs (https://github.com/uncurl/uncurl-support) in the docs page :)
We use libcurl and pycurl where it makes sense. This rule for cli options extends to other binaries as well, some that don’t offer libraries like curl does (think closed source firmware tools or ancient homegrown cli tools.)
Security is a top priority for this project, and I'm actively working to tighten things up. This initial version was launched to validate the concept, and admittedly, there were oversights (including an unauthenticated DELETE endpoint that was highlighted).
If you're open to it, I'd love to learn more about what you'd want to see from a security standpoint in a tool like this. I'm building in public and happy to be corrected where needed.
Thanks again for keeping things real.
Maybe the only solution is to somehow extract the actual command line parser from curl itself.
https://uncurl.dev/curl/78ab4bf5-34e8-45a0-b3b1-32dd6aa7e360
or this command
curl -X DELETE "https://uncurl.dev/api/curls?id=051606b5-49c8-4f14-9689-4d424f71d331"
Yes, delete is unauthenticated as highlighted, will be working on a fix for this. And you can delete any API if it is created as a logged in user.
Your project looks very cool though, and expands on the share aspect of the Jetbrains feature, very interesting!
uncurl.dev kind of grew out of that same spirit, but with the goal of making the output shareable and executable in a browser, especially for folks who might not have an IDE set up or are outside the usual dev loop (PMs, etc.)
Lately I feel like a lot of people think they are finding gaps around developer experience, but it's only because they don't know the right tools that already exist...
`curl www.google.com` works using 8.7.1 on macOS, but I get "Please enter a valid curl command" on your website.
You can absolutely delete your curl if you have created as a logged in user.
I would 100% forbid its use in a company environment and I would encourage people in general not to use it for any non-trivial use case.
One thing: it's rejecting dict lookups as invalid URL, eg. `curl dict://dict.org/d:failure:fd-eng-fra`
I'm checking first here whether I missed something in the docs about not supporting DICT before I add issue to the GH repo
I hadn’t actually considered dict:// usage, I see the bug report as well, thanks, will see if I can include it.
Non-logged in curls are auto purged after 30 days.
Could you describe more about the docker sandbox that you have? I am especially interested in the network restrictions.
The container has restricted outbound access—only HTTP/S requests are allowed. It runs inside an isolated network namespace with no access to the host network or other infrastructure components. There's no inbound access, and the container can't receive unsolicited requests from the outside world.
The sandbox container can only communicate with other containers in the same network, the main application container and sandbox container are on the same network, allowing them to communicate.
Do you think there could be ways for someone to abuse the network setup you have?
For example, accessing other internet hosts or other containers in the same container network?
What happens when curl gets redirect responses?
I have a feature working to allow users browser side execution, but as others have also pointed out CORS is a big blocker for client side execution not working for all APIs.
Local execution could still be a handy feature for at least the most common basic commands though, but it'd start to have to wade into "explaining a lot to the user why this isn't really what the result might look like" territory.