Hacker News Reader

Comment by ajnin | Hacker News Reader

Hum I'm definitely not the target for this but I don't see the value to obfuscate all the info in an UUID, I'd have kept things simple and stored things into an URL fragment, that way it's possible to operate client-side only and nothing gets leaked to a server I don't know much about like headers or whatever tokens or API keys could be passed in an URL.

View on HN

I see a fair bit of utility here. We have an API product, and (despite having pretty clear docs) I almost always have to send people curl requests they can copy and run.

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.

Totally with you on that—your use case is exactly what I had in mind when I built uncurl.dev.

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.

could also just do the request in javascript instead of needing a (presumably hosted) sandbox

curl supports many things javascript doesn't. Like http proxies, tls versions, and half the other flags

There are many types of request that cannot be made with client-side JS alone, but for those that can, the ability to send those requests client-side would be handy.

I think that 99.9% of CURL commands are copied from Chrome/Firefox's network inspector and are the simple "client-side JS" types.

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.

Even for commands that use the subset of cURL features that fetch supports, most requests to other domains (cross origin requests) wouldn't work anyway because the responses won't have the CORS[0] headers to allow being accessed from arbitrary websites. So running it client side would be infeasible for most requests.

[0]: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/COR...

Exactly — this was one of the core constraints I ran into early on.

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.

Reply on news.ycombinator.com