Comment by ajnin

13 days ago

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.

8 comments

ajnin

Reply
themanmaran  12 days ago

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.

  • darubramha  12 days ago

    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.

aae42  13 days ago

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

  • TheDong  13 days ago

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

  • ultrafez  13 days ago

    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.

    • markerz  12 days ago

      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.

      2 replies →