4 ms·

I can't even imagine the scale of the impact with Axios being compromised, nearly every other project uses it for some reason instead of fetch (I never understo

• beart 6mo ago
  > nearly every other project uses it for some reason instead of fetch (I never understood why). Fetch wasn't added to Node.js as a core package until version 18, and wasn't considered stable until version 21. Axios has been around much longer and was made part of popular frameworks and tutorials, which helps continue to propagate it's usage.
  • seer 6mo ago
    Also it has interceptors, which allow you to build easily reusable pieces of code - loggers, oauth, retriers, execution time trackers etc. These are so much better than the interface fetch offers you, unfortunately.
    • reactordev 6mo ago
      You can do all of that in fetch really easily with the init object. fetch('https://api.example.com/data', { headers: { 'Authorization': 'Bearer ' + accessToken } })
      • mhio 6mo ago
        What does an interceptor in the RequestInit look like?
        • reactordev 6mo ago
          A wrapper function around fetch… that’s what interceptors are…
      • zdragnar 6mo ago
        There are pretty much two usage patterns that come up all the time: 1- automatically add bearer tokens to requests rather than manually specifying them every single time 2- automatically dispatch some event or function when a 401 response is returned to clear the stale user session and return them to a login page. There's no reason to repeat this logic in every single place you make an API call. Likewise, every response I get is JSON. There's no reason to manually unwrap the response into JSON every time. Finally, there's some nice mocking utilities for axios for unit testing different responses and error codes. You're either going to copy/paste code everywhere, or you will write your own helper functions and never touch fetch directly. Axios... just works. No need to reinvent anything, and there's a ton of other handy features the GP mentioned as well you may or may not find yourself needing.
        • anon7000 6mo ago
          Helper functions seem trivial and not like you’re reimplementing much.
          • creshal 6mo ago
            Don't be silly, this is the JS ecosystem. Why use your brain for a minute and come up with a 50 byte helper function, if you can instead import a library with 3912726 dependencies and let the compiler spend 90 seconds on every build to tree shake 3912723 out again and give you a highly optimized bundle that's only 3 megabytes small?
        • sayamqazi 6mo ago
          > usage patterns IMO interceptors are bad. they hide what might get transformed with the API call at the place it is being used. > Likewise, every response I get is JSON. There's no reason to manually unwrap the response into JSON every time. This is not true unless you are not interfacing with your own backends. even then why not just make a helper that unwraps as json by default but can be passed an arg to parse as something else
        • arghwhat 6mo ago
          Interceptors are just wrappers in disguise. const myfetch = async (req, options) => { let options = options || {}; options.headers = options.headers || {}; options.headers['Authorization'] = token; let res = await fetch(new Request(req, options)); if (res.status == 401) { // do your thing throw new Error("oh no"); } return res; } Convenience is a thing, but it doesn't require a massive library.
    • meekins 6mo ago
      It also supports proxies which is important to some corporate back-end scenarios
      • nathanmills 6mo ago
        fetch supports proxies
  • nedt 6mo ago
    Before that we had node-fetch. If you already use a dependency why not one that's pretty much what will come natively to every JS runtime soon.
    • zarzavat 6mo ago
      The fetch API is designed for browsers. It's not designed for servers. Fetch may work for a particular use case on the server, it may not. Servers have needs over and above what a browser allows the client to do.
      • nedt 6mo ago
        Now I'm curious, because we have a big server side code base using fetch(). What are you using that doesn't work with fetch? Especially since axios nowadays has a fetch adapter.
  • zadikian 6mo ago
    Right. Though I would've used the built in xhr then. Not going to install a dep just to make http calls.
• martmulx 6mo ago
  [flagged]
  • dawnerd 6mo ago
    From what I can tell, it blocks it everywhere.
    • martmulx 6mo ago
      [flagged]
      • homebrewer 6mo ago
        After using pnpm for years (at least 5, don't remember exactly), I've only ever had to whitelist one library that uses a postinstall script to download a native executable for your system. And even this is not necessary, it's just poorly designed. For example, esbuild and typescript 7 split binaries for different systems and architectures into separate packages, and rely on your package manager to pull the correct one.
  • arcfour 6mo ago
    It prompts for transitive dependencies, too. I have never had workerd as a direct dependency of any project of mine but I get prompted to approve its postinstall script whenever I install cloudflare's wrangler package (since workerd needs to download the appropriate Workers runtime for your platform).
• eviks 6mo ago
  > Good news for pnpm/bun users who have to manually approve postinstall scripts. Would they not have approved it for earlier versions? But also wouldn't the chance of addition automatic approval be high (for such a widely used project)?
  • arcfour 6mo ago
    The prompt would be to approve the new malicious package (plain-crypto-js)'s scripts, too, which could tip users off that something was fishy. If they were used to approving one for axios and the attackers had just overwrote axios's own instead of making a new package, it would probably catch people out.
  • h4ch1 6mo ago
    Can't speak for other devs but I like to read postinstall scripts or at least put them through an LLM if they're too hard to grok. It's also a little context dependent, for example if I was using Axios and I see a prompt to run the plain-crypto-js postinstall script, alarm bells would instantly ring, which would at least make me look up the changelog to see why this is happening. In most cases I don't even let them run unless something breaks/doesn't work as expected.
  • bpev 6mo ago
    Assuming axios didn't have a postinstall script before, it wouldn't have been approved for a previous version. If you ignore it, you ignore it, but postinstall scripts are relatively rare in npm deps, so it would seem a bit out of place when the warning pops up.
• deleted 6mo ago
  [deleted]
• PunchyHamster 6mo ago
  > I can't even imagine the scale of the impact with Axios being compromised, nearly every other project uses it for some reason instead of fetch (I never understood why). You can remember this answer for every time you ask same question again: "Coz whatever else/builtin was before was annoying enough for common use cases"
• TZubiri 6mo ago
  >(I never understood why). Because axios existed before the builtin fetch, and so there's a lot of stackoverflow answers explaining how to use fetch, and the llm models are trained on that, so they will write axios requests instead of fetch
• benoau 6mo ago
  > (I never understood why). I spent two years trying to get it out of a project that began long after Axios had become redundant but it's very hard to go back and challenge decisions like this because every business priority is aligned against this kind of work. I expect libraries built on top of fetch will be the next to be compromised, because why would you use fetch without an arbitrary layer of syntactic sugar...
  • pyrolistical 6mo ago
    There was never the business value. But now remember this axios case and use it as ammo for the next issue. Just don’t abuse it