19 ms·

How to Hack APIs in 2021

334 points by sharestuff 5y ago

azalemeth 5y ago
Interesting article. I for one absolutely hate single page web applications. Amongst other things, it out-sources a lot of the computational load from the business to the customer, and they have a habit of riding roughshod over a user's browser preferences, patterns, and desires -- leading to a proliferation of grease monkey scripts and umatrix use amongst technical users and I suspect frustration among everyone else. Moreover, as this article shows, rather than exposing a finite number of "user data input" devices, you have to expose literally all your APIs and make them secure and robust. I just inherently think that's a larger attack surface.
- mewpmewp2 5y ago
  This would also depend on the implementation.
- unlimit 5y ago
  I also always have the same tick at the back of my head. I have put off learning/playing around with all SPA technologies because of this. To me it looks like we are increasing the surface area for a attack - again this is a hunch, a kind of smell test. But I also see that react etc are running away with all job offers.
- resonious 5y ago
  I'm finding it hard to grasp the effective difference between an SPA and a traditional webpage when it comes to security. The only real difference is your Content-Type, right? SPAs usually serve more JSON, and traditional pages serve more HTML. "Oops I accidentally exposed the wrong API" is basically the same as "oops I accidentally failed to lock down /admin/orders". I think all of the examples in the article are not specific to SPAs or "APIs" at all, and can all occur on any public HTTP endpoint that does any kind of real work.
  - ridaj 5y ago
    In theory yes, in practice I've observed many seasoned software engineers operate without being paranoid enough about the fact that APIs they publish can be hit by clients other than the one they designed.
  - marcosdumay 5y ago
    In a server rendered site, the developers create pages with a complete model of the user interaction on their heads. On a SPA, the API tends to be data-driven, so the backend developers have no idea what users will access what data, and why. There's nothing inherent about that. You can design a server rendered site using only generic data-driven pages, and you can design an SPA API with a concrete interaction model. But, for some reason, people tend to not do those.
  - Winsaucerer 5y ago
    Depends on your API, I think. API's are usually more flexible and powerful than the rendered pages that make use of them. At some point, we have to lock down the data. And in a server rendered multi-page website (henceforth just 'MPA'), that point is on each page, while for an SPA it's in the API. In an SPA, we call the API to fetch x, y, & z to render it. In an MPA, we query the database to fetch x, y, & z to render it. Since the query to the database is entirely server side, it does not need to be locked down in the same way that the API does. Mentally, it's a lot easier to look at the /admin/orders page and say "should this user be able to see all this data that I can see is visible?". It's a lot harder to wrap your head around all the myriad ways that someone might call the API, and understand whether you've let anything slip through. With the MPA, those items that shouldn't be there should be pretty obvious, just by looking at the page and seeing what data is visible. For an MPA, the data available to the client is all and only what is rendered on a page. For an SPA, it's all and only what is available through the API. You'll be looking at rendered pages frequently as you develop, but you will rarely (never?) be looking at the full possible output of the API. Some people will lock down which queries can be called against the API in production. This can mitigate some of the issues here, and is probably good practice for websites that aren't intending to make their API available directly. Particularly GraphQL API's.
niknetniko 5y ago
> These apps [single page web applications] also tend to feel snappier because page loads are not required for every request. This isn't my experience at all, especially when network conditions are not great. The browsers has error handling and a progress bar. Single page web applications often have bad or no error handling and you have no idea if the request failed, the code errored or something else went wrong. You need to refresh the whole page if something goes wrong, which results in having to load a ton of JS every again, negating all possible savings in time and data usage.
- ducktective 5y ago
  Exactly. The only time I felt the supposed "snappiness" is for documentation websites (so mainly text) that pre-fetch all links.
- unlimit 5y ago
  I agree and I hate two things about SPAs. - Works terrible in bad networks. - And the thing I hate the most is the shifting of images, links when the page is still loading. But this may be a implementation issue.
  - GrumpyNl 5y ago
    "- And the thing I hate the most is the shifting of images, links when the page is still loading. But this may be a implementation issue." Thats just bad design.
    - unlimit 5y ago
      I suspected that too, but I do not know enough about these reactive frameworks to be 100% sure. But as a user of such apps, it is absolutely frustrating.
      - Normal_gaussian 5y ago
        To stop jumping you need to explicitly size yet-to-load sections. Without JS this means giving images explicit sizing, with JS this means any section can be dynamically loaded and, therefore, jump. So good design takes into account dynamic loading and places size bounds accordingly. Reactive libraries/frameworks don't explicitly make this worse or better, except their presence implies a high chance of dynamic loading and, therefore, more opportunity for bad design. In addition most component libraries fail to communicate /who/ needs to size a component and if it is ever dynamic. It really doesn't help that most 'official' examples fail to resolve these issues.
cmsefton 5y ago
One of the best resources out there to learn about API hacking has to be OWASP Juice Shop https://owasp.org/www-project-juice-shop/ https://owasp.org/www-project-juice-shop/ We ran it as an exercise at work to learn about security vulnerabilities, and it was great fun and highly educational. Really recommend it.
- hellectronic 5y ago
  Yeah I can confirm this. We did it in our company too and it was really fun!
  - KajMagnus 5y ago
    > did it in our company How much time did it take? (for one person to do it)
- ineptech 5y ago
  I'm intrigued, could you elaborate on how you ran it? Was it a one-day event, or something people did in their 10% time, or something else?
  - cmsefton 5y ago
    Sure, we ran it over a couple of months. Generally, people did it in their spare time outside of office hours, or in 10% time. As long as it didn't impact work delivery. Everyone installed it locally using docker, and then we had a centralised server that ran the scoreboard for everyone to share and add their capture the flag tokens. We did a couple of presentations about interesting solutions as well to drum up support. We did a write-up on our blog if you're interested: https://purplelabs.eagleeye.com/blog/the-hackathon-capture-the-flag https://purplelabs.eagleeye.com/blog/the-hackathon-capture-t...
    - ineptech 5y ago
      Thank you!
barapa 5y ago
The moment the author mentioned SPAs as feeling snappier, you could predict that would be the main topic of discussion in the HN comments.
- granshaw 5y ago
  Yeah it’s disappointing, really.
snalty 5y ago
I hate SPAs but I like APIs as I can build my own programs that add missing features to make my life easier.
kace91 5y ago
>Baaackkk iiin myyy dayyyyy APIs were not nearly as common as they are now. This is due to the explosion in the popularity of Single Page Applications (SPAs). 10 years ago, web applications tended to follow a pattern where most of the application was generated on the server-side before being presented to the user. I know it's nitpicking and not the point of the article, but I don't think that's true. APIs have become commonplace because of the rise of mobile apps, that need one to talk to the back end. SPAs are in turn a response to the universality of APIs, because single page apps let you handle the browser as one more of those N clients, and avoid maintaining dofferent points of entrance to your backend. I bring this point up because people seem to hate SPAs (usually for good reasons) and it's important to realize the problem they're solving. Better handling of complex client side logic and the like, which are usually pointed at as the main benefits of SPAs, are usually just an afterthought by companies, since the percentage of SPAs that reach a level of complexity where that's an issue is relatively quite low.
- marcellus23 5y ago
  Eh? Couldn’t you just as easily make a traditional web app that’s just another client? Why does it need to be an SPA to use an API?
shreddit 5y ago
My company is distributor of a document-management-software, which also provides an API which connects directly to the underlying database. It's a very basic one i would never let touch the internet directly. 2 weeks ago i saw that another partner did connect it directly to the web with an angular frontend, exposing the login credentials (baked in the frontend). So their database is basically open to the world. I told them, but they responded with something like "We are currently unable to change that. There are plans to change that in the future though".
- ta988 5y ago
  Wait... you have nobody in charge of security in your company?
kall 5y ago
Kids these days have it so easy. It used to be you needed to scrape html pages and submit forms to get at someone else‘s data. Now all you need to do is grab their GraphQL endpoint from devtools and you‘re off to the races.
ridaj 5y ago
The other big push for APIs comes from mobile apps, which also tend to follow a model close to the web's single-page applications. Would be good to have a reliable setup to do this from iPhone and Android devices.
- conductr 5y ago
  > Would be good to have a reliable setup to do this from iPhone and Android devices. I'm curious what you mean by this "reliable setup" part. Can you elaborate?
  - ridaj 5y ago
    The part of the article where the researcher explains how to inspect and spoof API traffic (it's very web centric)
stadium 5y ago
I'm learning to build front end with Vue.js and it supports SPA with client side rendering with multiple routes. I intentionally choose this to take advantage of cheap (free) static site hosting, and the learning curve is easier without having to think about server management. I didn't realize until this project that a dynamic, reactive site can use static hosting. Vue has been a pleasure to work with. It supports server side rendering too but do far I haven't needed it.
- depressedpanda 5y ago
  Once you get more comfortable with Vue, I suggest you start looking into making the project a PWA so that it may work offline and can be "installed" by the user (if it suits your use case). I've written a fully statically served, backendless PWA, that uses the browsers local storage for persistent data, meaning that the data is fully private and owned by the user. If a user needs to sync their data between clients, they can connect the app to their Dropbox or Google Drive. There's even a chat implemented with WebRTC which allows users to communicate directly with each other, without a backend. If you disregard the JS haters on HN, you'll realize you can do some amazing things in the pure browser runtime nowadays.
  - stadium 5y ago
    Interesting, that must be what I installed to get the Vue docs as an app. I hadn't heard the term PWA, thanks for sharing.
singlow 5y ago
Not sure why this author thinks this is all so recent. I hacked my first web API in 1998 and it was exactly like an API for an SPA but they didn't call it REST back then. The content type was multipart/form-data and the results were sent in formatted html, but other than that it was still a series of url endpoints with an authentication header and input document. Sure, your average static content site didn't use an API in 1998, but WordPress/Drupal sites have exposed poorly secured APIs since the early 2000s even if the standard front-end didn't use them for content display.
- dr-detroit 5y ago
  When I was 11 I used to click the big goofy button in Netscape Navigator that would view source and then I would hunt for passwords to logins. Hacking is for the low IQ smoothbrain thats why slavs do it all day ere day sorry not sorry get off my google analytics you scum and then you can earn my respect.
- deleted 5y ago
  [deleted]
- btbuildem 5y ago
  Your web API hack may predate this author..
- efficax 5y ago
  XMLHttpRequest wasn't introduced (in IE!) until 1999, and almost nobody was using until after 2000. So how did you do make that work without a client side request mechanism?
  - jeroenhd 5y ago
    ActiveX is from. 1996, and java applets are from 95. I'm not sure if those technologies were capable of much back then, but the web used to be a much more diverse place before traditional plugins got purged and replaced by Javascript; I'd argue that javascript would be the worst way to do any kind of interactive website back in those days, because almost everyone was on Windows and the alternatives were so much more useful.
contravariant 5y ago
Well I suppose breaking security is one thing, in most cases webpages don't really see to realise how much access they've already given you though. Things you'd normally need to scrape the webpage for become a lot easier when you can just adapt the few HTTP requests you can easily identify with the network tab in most browsers.
jicea 5y ago
Testing apis with Postman is really interesting and you can learn a lot just by inspecting requests with the browser’s developper tools. We’ve build a command line tool [1] to be able to simply add integration tests in our CI/CD pipeline for our website (that was difficult with just Postman or Selenium) [1]: https://hurl.dev https://hurl.dev
- avel 5y ago
  Thanks for posting, this is interesting. It also reminds me of the file format and simplicity of the REST Client VS Code plugin: https://marketplace.visualstudio.com/items?itemName=humao.rest-client https://marketplace.visualstudio.com/items?itemName=humao.re...
travisjungroth 5y ago
> Instead, different components of the same page will update magically, giving it a similar feel to a native application. This model has also become more popular because ten billion ⁽ᶜᶦᵗᵃᵗᶦᵒⁿ ⁿᵉᵉᵈᵉᵈ⁾ different frontend JavaScript frameworks (React, Vue and Angular, etc.) have come into existence. Seems like a real "wet sidewalks cause rain" story. The model was becoming more popular among developers and then they made frameworks seems more likely than the other way around. Then the "ten billion" part. The three frameworks he listed dominate. Everything in "etc." is minor in comparison. I find this meme about JS frameworks lazy. (Note: totally a web backend person, so I should be the first to do the teasing). There seem to be much more boring answers: 1. With some exceptions (ClojureScript, TypeScript, Elm, ...), everyone who writes for the browser is forced to write JS. On the backend, people can express different opinions by using different languages (Python, Ruby, Java, Elixir, ...). So people that would split themselves into language camps on the backend are more likely to split into framework camps on the frontend. 2. The frontend environment is constantly changing (browsers) so the code is going to be churnier. You can't just not upgrade like you can on the backend. 3. User interfaces are more iterative than backend stuff, so the code is going to be churnier. 4. All this churn makes a rewrite more accessible and tempting. I just find it easier to believe that there's some difference in the constraints and freedoms of JS devs that causes them to make more (but not really that many more) frameworks, rather than there's some secret character flaw or something.
JaggerFoo 5y ago
Excellent article - it kept my interest to the end. I bookmarked and google several references in the article. Now I need to see an article on modern API development methods, including trusted frameworks. Cheers
einpoklum 5y ago
The top 7ee1 script kiddies in the world gather... let marvel at the wonder of the cracking of an SPA some poor underpaid subcontractor put together in a couple of weeks.
pengwing 5y ago
This thread definitely helped me to understand that there is a huge market demand for a Youtube series teaching how to write decent SPAs with React and also how to properly secure an API. Leave a reply if you want to be notified when the content is ready.
singingfish 5y ago
Heh, I did some work for these guys a few years ago. Good to see they're still about.
mooreds 5y ago
Note that this article has an error. "This section could contain anything, but at minimum it needs to contain some kind of user identifier and a timeout (iat)." The iat claim is when the token was issued, not when it expires. The exp claim is when it expires. See also https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.4 https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.4

334 points by sharestuff 5y ago

Interesting article. I for one absolutely hate single page web applications. Amongst other things, it out-sources a lot of the computational load from the business to the customer, and they have a habit of riding roughshod over a user's browser preferences, patterns, and desires -- leading to a proliferation of grease monkey scripts and umatrix use amongst technical users and I suspect frustration among everyone else. Moreover, as this article shows, rather than exposing a finite number of "user data input" devices, you have to expose literally all your APIs and make them secure and robust. I just inherently think that's a larger attack surface.

mewpmewp2 5y ago
This would also depend on the implementation.
unlimit 5y ago
I also always have the same tick at the back of my head. I have put off learning/playing around with all SPA technologies because of this. To me it looks like we are increasing the surface area for a attack - again this is a hunch, a kind of smell test. But I also see that react etc are running away with all job offers.
resonious 5y ago
I'm finding it hard to grasp the effective difference between an SPA and a traditional webpage when it comes to security. The only real difference is your Content-Type, right? SPAs usually serve more JSON, and traditional pages serve more HTML. "Oops I accidentally exposed the wrong API" is basically the same as "oops I accidentally failed to lock down /admin/orders". I think all of the examples in the article are not specific to SPAs or "APIs" at all, and can all occur on any public HTTP endpoint that does any kind of real work.
- ridaj 5y ago
  In theory yes, in practice I've observed many seasoned software engineers operate without being paranoid enough about the fact that APIs they publish can be hit by clients other than the one they designed.
- marcosdumay 5y ago
  In a server rendered site, the developers create pages with a complete model of the user interaction on their heads. On a SPA, the API tends to be data-driven, so the backend developers have no idea what users will access what data, and why. There's nothing inherent about that. You can design a server rendered site using only generic data-driven pages, and you can design an SPA API with a concrete interaction model. But, for some reason, people tend to not do those.
- Winsaucerer 5y ago
  Depends on your API, I think. API's are usually more flexible and powerful than the rendered pages that make use of them. At some point, we have to lock down the data. And in a server rendered multi-page website (henceforth just 'MPA'), that point is on each page, while for an SPA it's in the API. In an SPA, we call the API to fetch x, y, & z to render it. In an MPA, we query the database to fetch x, y, & z to render it. Since the query to the database is entirely server side, it does not need to be locked down in the same way that the API does. Mentally, it's a lot easier to look at the /admin/orders page and say "should this user be able to see all this data that I can see is visible?". It's a lot harder to wrap your head around all the myriad ways that someone might call the API, and understand whether you've let anything slip through. With the MPA, those items that shouldn't be there should be pretty obvious, just by looking at the page and seeing what data is visible. For an MPA, the data available to the client is all and only what is rendered on a page. For an SPA, it's all and only what is available through the API. You'll be looking at rendered pages frequently as you develop, but you will rarely (never?) be looking at the full possible output of the API. Some people will lock down which queries can be called against the API in production. This can mitigate some of the issues here, and is probably good practice for websites that aren't intending to make their API available directly. Particularly GraphQL API's.

niknetniko 5y ago

> These apps [single page web applications] also tend to feel snappier because page loads are not required for every request. This isn't my experience at all, especially when network conditions are not great. The browsers has error handling and a progress bar. Single page web applications often have bad or no error handling and you have no idea if the request failed, the code errored or something else went wrong. You need to refresh the whole page if something goes wrong, which results in having to load a ton of JS every again, negating all possible savings in time and data usage.

ducktective 5y ago
Exactly. The only time I felt the supposed "snappiness" is for documentation websites (so mainly text) that pre-fetch all links.
unlimit 5y ago
I agree and I hate two things about SPAs. - Works terrible in bad networks. - And the thing I hate the most is the shifting of images, links when the page is still loading. But this may be a implementation issue.
- GrumpyNl 5y ago
  "- And the thing I hate the most is the shifting of images, links when the page is still loading. But this may be a implementation issue." Thats just bad design.
  - unlimit 5y ago
    I suspected that too, but I do not know enough about these reactive frameworks to be 100% sure. But as a user of such apps, it is absolutely frustrating.
    - Normal_gaussian 5y ago
      To stop jumping you need to explicitly size yet-to-load sections. Without JS this means giving images explicit sizing, with JS this means any section can be dynamically loaded and, therefore, jump. So good design takes into account dynamic loading and places size bounds accordingly. Reactive libraries/frameworks don't explicitly make this worse or better, except their presence implies a high chance of dynamic loading and, therefore, more opportunity for bad design. In addition most component libraries fail to communicate /who/ needs to size a component and if it is ever dynamic. It really doesn't help that most 'official' examples fail to resolve these issues.

cmsefton 5y ago

One of the best resources out there to learn about API hacking has to be OWASP Juice Shop https://owasp.org/www-project-juice-shop/ https://owasp.org/www-project-juice-shop/ We ran it as an exercise at work to learn about security vulnerabilities, and it was great fun and highly educational. Really recommend it.

hellectronic 5y ago
Yeah I can confirm this. We did it in our company too and it was really fun!
- KajMagnus 5y ago
  > did it in our company How much time did it take? (for one person to do it)
ineptech 5y ago
I'm intrigued, could you elaborate on how you ran it? Was it a one-day event, or something people did in their 10% time, or something else?
- cmsefton 5y ago
  Sure, we ran it over a couple of months. Generally, people did it in their spare time outside of office hours, or in 10% time. As long as it didn't impact work delivery. Everyone installed it locally using docker, and then we had a centralised server that ran the scoreboard for everyone to share and add their capture the flag tokens. We did a couple of presentations about interesting solutions as well to drum up support. We did a write-up on our blog if you're interested: https://purplelabs.eagleeye.com/blog/the-hackathon-capture-the-flag https://purplelabs.eagleeye.com/blog/the-hackathon-capture-t...
  - ineptech 5y ago
    Thank you!

barapa 5y ago

The moment the author mentioned SPAs as feeling snappier, you could predict that would be the main topic of discussion in the HN comments.

granshaw 5y ago
Yeah it’s disappointing, really.

snalty 5y ago

I hate SPAs but I like APIs as I can build my own programs that add missing features to make my life easier.

kace91 5y ago

>Baaackkk iiin myyy dayyyyy APIs were not nearly as common as they are now. This is due to the explosion in the popularity of Single Page Applications (SPAs). 10 years ago, web applications tended to follow a pattern where most of the application was generated on the server-side before being presented to the user. I know it's nitpicking and not the point of the article, but I don't think that's true. APIs have become commonplace because of the rise of mobile apps, that need one to talk to the back end. SPAs are in turn a response to the universality of APIs, because single page apps let you handle the browser as one more of those N clients, and avoid maintaining dofferent points of entrance to your backend. I bring this point up because people seem to hate SPAs (usually for good reasons) and it's important to realize the problem they're solving. Better handling of complex client side logic and the like, which are usually pointed at as the main benefits of SPAs, are usually just an afterthought by companies, since the percentage of SPAs that reach a level of complexity where that's an issue is relatively quite low.

marcellus23 5y ago
Eh? Couldn’t you just as easily make a traditional web app that’s just another client? Why does it need to be an SPA to use an API?

shreddit 5y ago

My company is distributor of a document-management-software, which also provides an API which connects directly to the underlying database. It's a very basic one i would never let touch the internet directly. 2 weeks ago i saw that another partner did connect it directly to the web with an angular frontend, exposing the login credentials (baked in the frontend). So their database is basically open to the world. I told them, but they responded with something like "We are currently unable to change that. There are plans to change that in the future though".

ta988 5y ago
Wait... you have nobody in charge of security in your company?

kall 5y ago

Kids these days have it so easy. It used to be you needed to scrape html pages and submit forms to get at someone else‘s data. Now all you need to do is grab their GraphQL endpoint from devtools and you‘re off to the races.

ridaj 5y ago

The other big push for APIs comes from mobile apps, which also tend to follow a model close to the web's single-page applications. Would be good to have a reliable setup to do this from iPhone and Android devices.

conductr 5y ago
> Would be good to have a reliable setup to do this from iPhone and Android devices. I'm curious what you mean by this "reliable setup" part. Can you elaborate?
- ridaj 5y ago
  The part of the article where the researcher explains how to inspect and spoof API traffic (it's very web centric)

stadium 5y ago

I'm learning to build front end with Vue.js and it supports SPA with client side rendering with multiple routes. I intentionally choose this to take advantage of cheap (free) static site hosting, and the learning curve is easier without having to think about server management. I didn't realize until this project that a dynamic, reactive site can use static hosting. Vue has been a pleasure to work with. It supports server side rendering too but do far I haven't needed it.

depressedpanda 5y ago
Once you get more comfortable with Vue, I suggest you start looking into making the project a PWA so that it may work offline and can be "installed" by the user (if it suits your use case). I've written a fully statically served, backendless PWA, that uses the browsers local storage for persistent data, meaning that the data is fully private and owned by the user. If a user needs to sync their data between clients, they can connect the app to their Dropbox or Google Drive. There's even a chat implemented with WebRTC which allows users to communicate directly with each other, without a backend. If you disregard the JS haters on HN, you'll realize you can do some amazing things in the pure browser runtime nowadays.
- stadium 5y ago
  Interesting, that must be what I installed to get the Vue docs as an app. I hadn't heard the term PWA, thanks for sharing.

singlow 5y ago

Not sure why this author thinks this is all so recent. I hacked my first web API in 1998 and it was exactly like an API for an SPA but they didn't call it REST back then. The content type was multipart/form-data and the results were sent in formatted html, but other than that it was still a series of url endpoints with an authentication header and input document. Sure, your average static content site didn't use an API in 1998, but WordPress/Drupal sites have exposed poorly secured APIs since the early 2000s even if the standard front-end didn't use them for content display.

dr-detroit 5y ago
When I was 11 I used to click the big goofy button in Netscape Navigator that would view source and then I would hunt for passwords to logins. Hacking is for the low IQ smoothbrain thats why slavs do it all day ere day sorry not sorry get off my google analytics you scum and then you can earn my respect.
deleted 5y ago
[deleted]
btbuildem 5y ago
Your web API hack may predate this author..
efficax 5y ago
XMLHttpRequest wasn't introduced (in IE!) until 1999, and almost nobody was using until after 2000. So how did you do make that work without a client side request mechanism?
- jeroenhd 5y ago
  ActiveX is from. 1996, and java applets are from 95. I'm not sure if those technologies were capable of much back then, but the web used to be a much more diverse place before traditional plugins got purged and replaced by Javascript; I'd argue that javascript would be the worst way to do any kind of interactive website back in those days, because almost everyone was on Windows and the alternatives were so much more useful.

contravariant 5y ago

Well I suppose breaking security is one thing, in most cases webpages don't really see to realise how much access they've already given you though. Things you'd normally need to scrape the webpage for become a lot easier when you can just adapt the few HTTP requests you can easily identify with the network tab in most browsers.

jicea 5y ago

Testing apis with Postman is really interesting and you can learn a lot just by inspecting requests with the browser’s developper tools. We’ve build a command line tool [1] to be able to simply add integration tests in our CI/CD pipeline for our website (that was difficult with just Postman or Selenium) [1]: https://hurl.dev https://hurl.dev

avel 5y ago
Thanks for posting, this is interesting. It also reminds me of the file format and simplicity of the REST Client VS Code plugin: https://marketplace.visualstudio.com/items?itemName=humao.rest-client https://marketplace.visualstudio.com/items?itemName=humao.re...

travisjungroth 5y ago

> Instead, different components of the same page will update magically, giving it a similar feel to a native application. This model has also become more popular because ten billion ⁽ᶜᶦᵗᵃᵗᶦᵒⁿ ⁿᵉᵉᵈᵉᵈ⁾ different frontend JavaScript frameworks (React, Vue and Angular, etc.) have come into existence. Seems like a real "wet sidewalks cause rain" story. The model was becoming more popular among developers and then they made frameworks seems more likely than the other way around. Then the "ten billion" part. The three frameworks he listed dominate. Everything in "etc." is minor in comparison. I find this meme about JS frameworks lazy. (Note: totally a web backend person, so I should be the first to do the teasing). There seem to be much more boring answers: 1. With some exceptions (ClojureScript, TypeScript, Elm, ...), everyone who writes for the browser is forced to write JS. On the backend, people can express different opinions by using different languages (Python, Ruby, Java, Elixir, ...). So people that would split themselves into language camps on the backend are more likely to split into framework camps on the frontend. 2. The frontend environment is constantly changing (browsers) so the code is going to be churnier. You can't just not upgrade like you can on the backend. 3. User interfaces are more iterative than backend stuff, so the code is going to be churnier. 4. All this churn makes a rewrite more accessible and tempting. I just find it easier to believe that there's some difference in the constraints and freedoms of JS devs that causes them to make more (but not really that many more) frameworks, rather than there's some secret character flaw or something.

JaggerFoo 5y ago

Excellent article - it kept my interest to the end. I bookmarked and google several references in the article. Now I need to see an article on modern API development methods, including trusted frameworks. Cheers

einpoklum 5y ago

The top 7ee1 script kiddies in the world gather... let marvel at the wonder of the cracking of an SPA some poor underpaid subcontractor put together in a couple of weeks.

pengwing 5y ago

This thread definitely helped me to understand that there is a huge market demand for a Youtube series teaching how to write decent SPAs with React and also how to properly secure an API. Leave a reply if you want to be notified when the content is ready.

singingfish 5y ago

Heh, I did some work for these guys a few years ago. Good to see they're still about.

mooreds 5y ago

Note that this article has an error. "This section could contain anything, but at minimum it needs to contain some kind of user identifier and a timeout (iat)." The iat claim is when the token was issued, not when it expires. The exp claim is when it expires. See also https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.4 https://datatracker.ietf.org/doc/html/rfc7519#section-4.1.4