5 ms·

What have we forgotten?

98 points by sam_lowry_ 2y ago

Terr_ 2y ago
> I do not know what was the reason to get rid of session cookies. Maybe the fear of GDPR violations or Aren't regular session cookies already considered Strictly Necessary For Functionality?
- vmaurin 2y ago
  Yes they are! I think I know the reason: OAuth2 naming. In the OAuth rfc https://www.rfc-editor.org/rfc/rfc6749 https://www.rfc-editor.org/rfc/rfc6749 they named one of the role "client", but than meant to represent a server in the more standard flow, while they named the browser "user-agent". Then people understood that "client" is the browser, so they went nuts storing access token and refresh token in the browser local storage, instead of being store in the server session storage, accessible with a session cookie. So what people should have done https://www.rfc-editor.org/rfc/rfc6749#section-4.1 https://www.rfc-editor.org/rfc/rfc6749#section-4.1 (you can see here the tokens never reach the user agent, so the server can keep them in a session, then have the user agent identified by a cookie. And what most of the people did https://www.rfc-editor.org/rfc/rfc6749#section-4.2 https://www.rfc-editor.org/rfc/rfc6749#section-4.2
  - sam_lowry_ 2y ago
    This is a very useful piece of information. According to the saying "There are two hard problems in Computer Science: naming things and cache invalidation"... OAuth 2.0 editors failed to properly name things.
  - mariusor 2y ago
    But there are many times when the client _is_ the browser. Are you sure you're not confused by that?
    - vmaurin 2y ago
      In the RFC, the browser is named "user-agent". And in OAuth2 flow, the browser is acting as client only on the implicit flow. Also the intent of the authors for the implicit flow is that the "client" is a mobile/desktop applications, and not especially something running in a browser
      - mariusor 2y ago
        Yes, but I think there are plenty of OAuth2 libraries/clients implemented in ts/js to be used directly from a web application. A JavaScript client running in a web-page still presents itself to the OAuth2 server as the regular "User-Agent" that's used for the web/HTML parts of the interaction unless the requests being done are enhanced with a custom header. For these clients saving the tokens in the local browser storage is the more elegant option in my opinion, to saving them in a cookie and thus polluting the rest of the browser's requests to that same host.
tjansen 2y ago
Seemingly we have also forgotten the pain brought by session cookies. Applications relying on session cookies typically broke when users opened several tabs and switched between them, users used the browser 'back' button or accessed the system with two devices simultaneously. It was difficult and required a lot of discipline to write a good application with session cookies. At least when you use them for more state than just authentication data. I for one am very happy that we have passed the age of session cookies. That doesn't mean that everything is perfect now, but applications generally work better than they used to do before the JS+API pattern.
- anonzzzies 2y ago
  A major part of the PHP crowd would beg to differ; it was always pretty trivial for both state and auth.
- WA 2y ago
  I think you're conflating something here. Whether you send a session ID in a cookie or a JWT makes no difference for the app's general behavior, even when you use multiple tabs or multiple devices. But I remember a time when especially bank websites added an additional token (like a super strict CSRF token) to their app, which tracked the current page of a user and if you browsed the same website from another tab, this other tab didn't have the proper token and the whole thing just returned "invalid user action" or something like that. However, this has nothing to do with session cookies.
  - tjansen 2y ago
    Typically, in the Weblogic days, session cookies were used to hold a server-side session containing the app state. If you just hold auth data in the session this is not a problem. But if hold state like form data in the session it becomes a huge source of errors. Virtually all non-trivial web-based applications had these issues 20 years ago (before „Ajax“). J2EE servers like Weblogic even supported stateful EJBs that brought server-side state to a new (insane) level. While you could theoretically use JWTs for the same purpose, they are typically only used for authentication. And back then JWT wasn’t a thing.
supplemental 2y ago
I think the author is not aware that most modern apps don’t interface with traditional files. Many modern apps rather use S3 with presigned urls.
- anonzzzies 2y ago
  ... in corps hn crowds hang; in companies we consult at (very large to very small), things are very different. From nfs, nas/san to just the filesystem. S3/etc is still rare I would say for where we go.
- bayindirh 2y ago
  Not everyone moves all their applications, files, kitchen sinks and glasses to cloud. There are still tons of traditional systems out there, and there's a small requirement for many of these organizations to have local, object storage systems.
- Cthulhu_ 2y ago
  Maybe, but the end user of a browser based application (what this post feels like it references) deals with regular files served over HTTP still. Its source may be S3 in the end, but ultimately it's webservers and files, be they self hosted or one of the major content distribution networks' servers. And that's absolutely fine, it's simple, highly optimized, standardized, etc. S3 blobs aren't and except for very specific use cases I wouldn't use it for serving files to end users.
- jemmyw 2y ago
  I think you've thrown around the words 'most' and 'many' a little too freely.
ozim 2y ago
Author is wrong but it would take me whole blogpost of its own. No cookies are not gone because of GDPR. You can have JWT token in a cookie. Having it in local storage is bad practice and it should be in http only cookie.
ThinkBeat 2y ago
It is a mysterious thing how the influencers of various kind in software engineering, have to jump from something new to something new. Even if the "new" new has been created a long time ago. Using old systems is in no way fashionable. Everyone wants the latest whatnot on their resume to be more attractive for future job opportunities. We are forever stuck in a fast fashion web. I like to think about typed vs non typed langauges For a long time they both existed in relativ harmony (much more so than emacs vs vi). Then it became the THE THING to use non typed langues. In part because "having to write the type in the code was far too much work". We got young software developers who had never used a type langauge but who had joined the "church of non typed". Skipping ahead, some influencer discovers typed languages and how it solves many problems. What about that. Choices are good. We can make informed choices as to what tool makes the most sense in the context of what we are trying to solve. (and its fit with the team and the legacy code etc)
- anilakar 2y ago
  Kubernetes is great. Legacy bash and cron is hip and cool again just because you can wrap stuff in a k8s cronjob.
- cultofmetatron 2y ago
  > Even if the "new" new has been created a long time ago. laughs in common lisp
  - tartoran 2y ago
    (+ ha ha ha ha)
- wruza 2y ago
  Having lived through all that I think it’s worth reminding that old typed languages were no match to modern ones. I’m not talking about arcane envs here, only about practical and widely used. People didn’t really go just “untyped”. Untyped simply was quicker in becoming easier to use and less screwed than the old. Or you may even view it as paving the road. Typed slowly catched up with the same quality under new names. This nuance is easy to miss, but set the cut off date to 2005 and recollect what your “options” were again. They weren’t that shiny.
mrkeen 2y ago
I don't know why the author blames Spring in this. You can't swing a dead cat in HN without someone saying "just use Spring, it handles session cookies for you automatically" Likewise why blame JWTs for needing to reauthenticate. Not needing to reauthenticate is JWTs unique selling point. And I don't think we developers ever knew how to write distributed systems. It sounds like the Weblogic guys did though.
Zanfa 2y ago
> I do not know what was the reason to get rid of session cookies. Maybe the fear of GDPR violations Just to clarify, GDPR has nothing to do with cookies. GDPR applies exactly the same whether you use cookies, JWTs in local or session storage, some magic session id tacked at the end of every URL or device fingerprinting.
- mbmjertan 2y ago
  I am not surprised. A lot of people conflate GDPR with the well-intentioned but misdirected cookie directive. A lot of people blame the EU for “forcing cookie banners onto the web”, while the GDPR solely demands that you ask for consent before storing data that’s outside of your core functional needs to operate the app/website. The UX of those dialogs is largely a dark pattern because the law did not demand implementation details, yet people blame GDPR because businesses designed them to be a nightmare to use. Yet people applaud for App Tracking Transparency dialogs. It’s ironic how the GDPR is painted as a villain.
  - Propelloni 2y ago
    > The UX of those dialogs is largely a dark pattern because the law did not demand implementation details, yet people blame GDPR because businesses designed them to be a nightmare to use. Yet people applaud for App Tracking Transparency dialogs. True, it does not mandate specific implementation details but in Recital 32 of the GDPR [1], it demands "request[s] must be clear, concise and not unnecessarily disruptive to the use of the service [...]" which is mostly not given with dark pattern implementations. [1] https://gdpr.eu/Recital-32-Conditions-for-consent/ https://gdpr.eu/Recital-32-Conditions-for-consent/
  - Zanfa 2y ago
    > The UX of those dialogs is largely a dark pattern because the law did not demand implementation details, yet people blame GDPR because businesses designed them to be a nightmare to use. IMO the law was clear enough as highlighted in the sibling comment. It is poor enforcement that's been a major issue. If a company registered in country A flouts GPDR, even in country B, there's nothing country B can do, other than delegate to country A's data protection / privacy authority. If country A then drags their feet and takes no action, we arrive at the current situation.
bfung 2y ago
As an older coder, past my 40s, the industry hasn’t forgotten, it’s just moved on. Distributed transactions across many microservice is too inefficient and complex to deal with. DT is fine if you don’t have microservices, scaling out quickly is hard otherwise. Session cookies likewise ~ how does authN and authZ work through each microservice without overloading a central service? JWTs do decently. Don’t use microservices? That’s a different debate.
- coldtea 2y ago
  >Distributed transactions across many microservice is too inefficient and complex to deal with. DT is fine if you don’t have microservices, scaling out quickly is hard otherwise. Perhaps microservices were the wrong idea then... Added complexity and splitting what is still conceptually a single coordinated operation. >Don’t use microservices? That’s a different debate If it's the proper debate though, we should get to it - not just ignore that part, and say "we moved on", as if we improved things...
  - nejsjsjsbsb 2y ago
    There is no we: everyone does it different. The term engineering that we stole from engineers implies making pragmatic decisions based on cost, complexity and requirements. Honestly I see the erring on the side of the traditional more than I do the extavagent in real life.
bingo-bongo 2y ago
> There is clearly a failure of engineering leadership. I am still puzzled why. I personally believe it’s lack of good engineering leadership and it’s only getting worse at this point. I’ve experienced a fair share of technical leaders without enough technical background and/or experience - people/leadership skills is equally important imho, but people with both are hard to find (scarce resource) and it seems like it’s often the tech side that gets compromised. I think one of the reasons is the IT industry is simply growing too fast, meaning we have a very small pool of people with many years of experience and a very large pool of people with less experience (compared to other industries). But we do need technical leaders, hence the compromise (need?) to pick people with less experience. Unfortunately.
- nopassrecover 2y ago
  As a rough generality, being good at something, like proper good at it, is incompatible with the basic forces of how modern organisations work. By this I mean the systems of reward, power, decision-making. That doesn’t mean all organisations work this way (mythically, startups of old didn’t), nor that some leaders can’t manage this tension, but tension it is which means while these leaders will often achieve “better” outcomes (that is, “more good” outcomes with relevance to the area of expertise or craft they’re good at, often but not always with more empathy and better working conditions for those delivering), they’ll also encounter more barriers to progressing to and maintaining positions of power, face greater scrutiny, probably be confused why the organisation around them isn’t understanding or valuing their capability (and spend a lot of time translating to frames they do understand and value), and ultimately greater burnout.
  - dasil003 2y ago
    I think the challenge is largely a matter of scale. Once you have thousands or tens of thousands of people, communication becomes by far the dominant factor in outcomes. You can set up different structures and cultural norms to try to nudge things in the right direction, but there is no org structure that can solve this because local details always matter. The trick is understanding which details matter and why. Ultimately I think this depends on management competence and judgement. I also think IC leadership is a critical counterweight to the distortions of empire building that incentivize creating messes. And finally as a competent individual you need the maturity to recognize the difference between unavoidable but tolerable organizational dysfunction, and broken leadership where its impossible to do good work, and hence time to cut bait and leave.
orf 2y ago
> The Weblogic servers were configured to enable distributed transactions, so … there was a high degree of assurance that there will be no data corruption nor race conditions. > we have forgotten how to make distributed apps Have you, really? Did you ever know? It sounds like you just: - used a framework (I hope the “high assurance” bit is a joke…) - then forgot to configure it correctly for a new deployment environment. Honestly, “Engineering excellence” and “we build things with Weblogic distributed transactions” are two things that are not commonly put together.
- sam_lowry_ 2y ago
  > “high assurance” bit is a joke… OP here. It is not, Weblogic distributed transactions are using two-phase commits under the hood. From the point of view of contemporary Computer Science, two-phase commits give up Availability in the CAP theorem. Deadlocks may still happen. The issue with moving from Weblogic to Kubernetes is that previously, Weblogic enforced consistency and prevented partitioning. With Kubernetes, this responsibility moved from the Weblogic to application developers. Were they prepared or empowered to take over? I think not all of them and not everywhere.
- sriram_malhar 2y ago
  Ouch! I wrote much of the Weblogic server's distributed transactions framework back in the day. Forget EJB (which too I wrote :(, but in my defense it was forced on us by IBM and Oracle, and I personally hated it). The JTA bit was a thin sliver over the various db and messaging product vendors' XA drivers, which differed in important and annoying ways. Some were not thread-safe (SQLServer), some drivers' connections had to be pinned to the same thread (Informix) etc. As a user, if you had to have distributed transactions, you would have done worse than Weblogic, methinks.
  - orf 2y ago
    Sorry! I didn’t mean to throw shade on your work. What I mean is that being able to turn a key in a car ignition doesn’t make one a car mechanic.
apples_oranges 2y ago
We try new things, keep what is useful and discard what is not. That is normal, why complain, just do what is best for your problem.
- Cthulhu_ 2y ago
  They complain because they discarded what is useful, breaking solved problems and needing to spend a lot of resources on working around that instead of solving the actual problem. But this is a recurring problem in software development, people spend all their energy on setup and innovation, and relatively little on the actual value.
szundi 2y ago
These are the new rockstar dev 20s devs who don’t know these and invent new ways - probably
andrewstuart 2y ago
Companies have outsourced their thinking to Amazon Web Services. Software developers and architects when faced with a problem, challenge, question about how to do things, simply look up the answer in Amazon Web Services documentation.
rednafi 2y ago
JWT is one of the worst things that came out of the JS frontend ecosystem and spread everywhere. It made working with services so much more cumbersome in the name of security. Then people started using it to carry contextual information, and now it’s pretty common to see ginormous tokens being sent out in every S2S call. Also, everyone loves working with obnoxiously short token refresh time.
- donatj 2y ago
  The number of times I have had to remind a developer that the contents of the JWT are readable is nuts. Way too often they want to treat it like a general session store and just toss any old state in there regardless of if the end user should be able to see the value.
  - feoren 2y ago
    The contents of a session cookie are also readable...
    - dasil003 2y ago
      I think he's talking about a server-side session store (or perhaps an encrypted cookie payload)
burgerrito 2y ago
> Screen readers and many kinds of web accessibility are barely useable, all that... because we have forgotten about session cookies. What did the author meant by this? In what way that accessibility and session cookie are related?
- donatj 2y ago
  My presumption would be a natively reliable back button. / navigation in general that doesn't end up accidentally losing your session
tpm 2y ago
> application server that synchronized state among instances Huge sessions that move frequently (even if the original developers understand this and are disciplined enough, the juniors that continue development of the app are not, so the session size grows). This eats all the available memory and is slow. So it's better to go if not completely stateless then at least restrict the session to a viable minimum.
roenxi 2y ago
There is a management principle here that the tech world doesn't seem to have internalised yet. It is linked to the basic problem that we can't measure programmer productivity. Software tends to be modularised based on a company's management structure. What the components do tends to reflect the manager. When the manager changes, the software either starts to change too or succumbs to bitrot. It is pretty normal for tech companies to start listing after the original founders move on - even a company like Google or Microsoft with money and technically strong individual employees starts to mean regress as new managers come in who have a different and murkier vision than the founders. With luck the transition can be from excellence to a different form of excellence, but the basic strategy people seem to have that management is to be encoded in the org structure and bureaucratic processes doesn't seem to work at preserving high-performing tech companies. It depends on specific people in key leadership positions. Because if they get swapped out there is no way to measure the productivity change less effective managers foist on developers until the company has notably mean regressed years later. I'd bet something like this happened here. A team lead or someone was swapped out and replaced with someone who thought differently.
- julik 2y ago
  Or, what happens sometimes, a "team lead or someone" was replaced with a pack of freshly appointed team leads, with nobody being positioned to "break ties" with them and with an explicit ban on any sane engineering guidance "because we don't want to depend on one person". Then those team leads would try to drive their teams and efforts in alignment with the ways they saw familiar or acceptable, and with zero interest for the "big picture" - they would be focused on the survival of their position and their team only. Fiefdoms would emerge, and every little such fiefdom would be pulling the rug its way. With disastrous consequences for all of security, end user convenience, stability, resilience and malleability of the system.
  - deltaburnt 2y ago
    The zero interest in big picture and fiefdoms hits home pretty hard. Even if a subgroup wants to put emphasis on the big picture that's just one more set of hands on the rug. Suddenly you're spending more time arguing and fighting political battles instead of building great stuff. You can win some battles, but you have to have amazing persistence to not burn out or retreat to your subgroup mentality after a while. I really don't care if I disagree with top level technical leadership. Having no technical leadership is even worse.
arkh 2y ago
Idea for your next article: progressive enhancement. I can't wait for people to discover it again.
- sam_lowry_ 2y ago
  Hah. Back in 2011 my team built a news website with adaptive delivery. It loaded a small html page with a javascript that checked the screen size and user agent, then based on whether the user was on a phone, a tablet or a desktop, downloaded and displayed the content crafted for that particular device. It then left a cookie to avoid the extra round-trip for returning visitors. Nowadays people tend to adapt the design to devices with CSS frameworks and flexbox layout, but this does not always reduce traffic and CPU time for low-powered devices. While our engineering feat was adorable and I praised the team for the achievement, this architecture did not last. The editorial team did not want to maintain essentially 3 different content layouts daily, the marketing team was not willing to compromise on ads on smaller screens. None was happy except the readers.
julik 2y ago
We haven't forgotten anything - rather we were forced to remain silent. https://blog.julik.nl/2024/03/those-people-who-say-no https://blog.julik.nl/2024/03/those-people-who-say-no I may do a writeup on how the mentioned things are very indicative of a certain org failure, since I've seen something very similar first hand.
DavidPiper 2y ago
> Screen readers and many kinds of web accessibility are barely useable, all that... because we have forgotten about session cookies. No I feel like screen readers and many kinds of web accessibility are barely useable because we forgot about screen readers and web accessibility.
jalk 2y ago
The browser session concept has “eroded” over time. Many, if not most, laptop users rarely closer all browser windows and hence sessions can last months. Haven’t checked but I wouldn’t be surprised if session cookies survive a browser update, started from the menu at
- Ekaros 2y ago
  It does. Google is good example. I have fully closed my computer for a while and restarted it and session is still there. It is amazing just how long they can last if you regularly use it.
  - jalk 2y ago
    I believe that google login cookies, are persistent cookies with a longish max-age/expires value, so that is not surprising, and hence why you have to use google periodically to "refresh" the cookies. Here is what MDN[1] says about session cookies: > Session cookies — cookies without a Max-Age or Expires attribute – are deleted when the current session ends. The browser defines when the "current session" ends, and some browsers use session restoring when restarting. This can cause session cookies to last indefinitely. I was unaware of the "session restoring" point. This has to be considered if wanting to "unforget" the use of session cookies. [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies (edit for layout)
throwaway_2494 2y ago
I share the author's frustration with this trend that _everything_ be a JSON object. Just recently I had some colleagues create a 200Mb JSON blob representing data records with the goal of querying the data in various ways. I instead loaded it into a SQL database and wrote a few queries which quickly got the job done. Also I totally agree that people have forgotten how to stream data via HTTP now, coming up with all sorts of crappy handcrafted approaches, often involving JSON. I've seen many sorry examples of this too. See: https://jargonfile.johnswitzerland.com/stone-knives-and-bearskins.html https://jargonfile.johnswitzerland.com/stone-knives-and-bear...
veqq 2y ago
Similar in spirit: https://rakhim.org/its-all-just-fashion-shows/ https://rakhim.org/its-all-just-fashion-shows/
deleted 2y ago
[deleted]
GuB-42 2y ago
> Access denied > You are not authorized to access this page. It seems we have forgotten the article. But not the Internet Archive https://web.archive.org/web/20250130030201/http://mikhailian.mova.org/node/291 https://web.archive.org/web/20250130030201/http://mikhailian...

98 points by sam_lowry_ 2y ago

> I do not know what was the reason to get rid of session cookies. Maybe the fear of GDPR violations or Aren't regular session cookies already considered Strictly Necessary For Functionality?

vmaurin 2y ago
Yes they are! I think I know the reason: OAuth2 naming. In the OAuth rfc https://www.rfc-editor.org/rfc/rfc6749 https://www.rfc-editor.org/rfc/rfc6749 they named one of the role "client", but than meant to represent a server in the more standard flow, while they named the browser "user-agent". Then people understood that "client" is the browser, so they went nuts storing access token and refresh token in the browser local storage, instead of being store in the server session storage, accessible with a session cookie. So what people should have done https://www.rfc-editor.org/rfc/rfc6749#section-4.1 https://www.rfc-editor.org/rfc/rfc6749#section-4.1 (you can see here the tokens never reach the user agent, so the server can keep them in a session, then have the user agent identified by a cookie. And what most of the people did https://www.rfc-editor.org/rfc/rfc6749#section-4.2 https://www.rfc-editor.org/rfc/rfc6749#section-4.2
- sam_lowry_ 2y ago
  This is a very useful piece of information. According to the saying "There are two hard problems in Computer Science: naming things and cache invalidation"... OAuth 2.0 editors failed to properly name things.
- mariusor 2y ago
  But there are many times when the client _is_ the browser. Are you sure you're not confused by that?
  - vmaurin 2y ago
    In the RFC, the browser is named "user-agent". And in OAuth2 flow, the browser is acting as client only on the implicit flow. Also the intent of the authors for the implicit flow is that the "client" is a mobile/desktop applications, and not especially something running in a browser
    - mariusor 2y ago
      Yes, but I think there are plenty of OAuth2 libraries/clients implemented in ts/js to be used directly from a web application. A JavaScript client running in a web-page still presents itself to the OAuth2 server as the regular "User-Agent" that's used for the web/HTML parts of the interaction unless the requests being done are enhanced with a custom header. For these clients saving the tokens in the local browser storage is the more elegant option in my opinion, to saving them in a cookie and thus polluting the rest of the browser's requests to that same host.

tjansen 2y ago

Seemingly we have also forgotten the pain brought by session cookies. Applications relying on session cookies typically broke when users opened several tabs and switched between them, users used the browser 'back' button or accessed the system with two devices simultaneously. It was difficult and required a lot of discipline to write a good application with session cookies. At least when you use them for more state than just authentication data. I for one am very happy that we have passed the age of session cookies. That doesn't mean that everything is perfect now, but applications generally work better than they used to do before the JS+API pattern.

anonzzzies 2y ago
A major part of the PHP crowd would beg to differ; it was always pretty trivial for both state and auth.
WA 2y ago
I think you're conflating something here. Whether you send a session ID in a cookie or a JWT makes no difference for the app's general behavior, even when you use multiple tabs or multiple devices. But I remember a time when especially bank websites added an additional token (like a super strict CSRF token) to their app, which tracked the current page of a user and if you browsed the same website from another tab, this other tab didn't have the proper token and the whole thing just returned "invalid user action" or something like that. However, this has nothing to do with session cookies.
- tjansen 2y ago
  Typically, in the Weblogic days, session cookies were used to hold a server-side session containing the app state. If you just hold auth data in the session this is not a problem. But if hold state like form data in the session it becomes a huge source of errors. Virtually all non-trivial web-based applications had these issues 20 years ago (before „Ajax“). J2EE servers like Weblogic even supported stateful EJBs that brought server-side state to a new (insane) level. While you could theoretically use JWTs for the same purpose, they are typically only used for authentication. And back then JWT wasn’t a thing.

supplemental 2y ago

I think the author is not aware that most modern apps don’t interface with traditional files. Many modern apps rather use S3 with presigned urls.

anonzzzies 2y ago
... in corps hn crowds hang; in companies we consult at (very large to very small), things are very different. From nfs, nas/san to just the filesystem. S3/etc is still rare I would say for where we go.
bayindirh 2y ago
Not everyone moves all their applications, files, kitchen sinks and glasses to cloud. There are still tons of traditional systems out there, and there's a small requirement for many of these organizations to have local, object storage systems.
Cthulhu_ 2y ago
Maybe, but the end user of a browser based application (what this post feels like it references) deals with regular files served over HTTP still. Its source may be S3 in the end, but ultimately it's webservers and files, be they self hosted or one of the major content distribution networks' servers. And that's absolutely fine, it's simple, highly optimized, standardized, etc. S3 blobs aren't and except for very specific use cases I wouldn't use it for serving files to end users.
jemmyw 2y ago
I think you've thrown around the words 'most' and 'many' a little too freely.

ozim 2y ago

Author is wrong but it would take me whole blogpost of its own. No cookies are not gone because of GDPR. You can have JWT token in a cookie. Having it in local storage is bad practice and it should be in http only cookie.

ThinkBeat 2y ago

It is a mysterious thing how the influencers of various kind in software engineering, have to jump from something new to something new. Even if the "new" new has been created a long time ago. Using old systems is in no way fashionable. Everyone wants the latest whatnot on their resume to be more attractive for future job opportunities. We are forever stuck in a fast fashion web. I like to think about typed vs non typed langauges For a long time they both existed in relativ harmony (much more so than emacs vs vi). Then it became the THE THING to use non typed langues. In part because "having to write the type in the code was far too much work". We got young software developers who had never used a type langauge but who had joined the "church of non typed". Skipping ahead, some influencer discovers typed languages and how it solves many problems. What about that. Choices are good. We can make informed choices as to what tool makes the most sense in the context of what we are trying to solve. (and its fit with the team and the legacy code etc)

anilakar 2y ago
Kubernetes is great. Legacy bash and cron is hip and cool again just because you can wrap stuff in a k8s cronjob.
cultofmetatron 2y ago
> Even if the "new" new has been created a long time ago. laughs in common lisp
- tartoran 2y ago
  (+ ha ha ha ha)
wruza 2y ago
Having lived through all that I think it’s worth reminding that old typed languages were no match to modern ones. I’m not talking about arcane envs here, only about practical and widely used. People didn’t really go just “untyped”. Untyped simply was quicker in becoming easier to use and less screwed than the old. Or you may even view it as paving the road. Typed slowly catched up with the same quality under new names. This nuance is easy to miss, but set the cut off date to 2005 and recollect what your “options” were again. They weren’t that shiny.

mrkeen 2y ago

I don't know why the author blames Spring in this. You can't swing a dead cat in HN without someone saying "just use Spring, it handles session cookies for you automatically" Likewise why blame JWTs for needing to reauthenticate. Not needing to reauthenticate is JWTs unique selling point. And I don't think we developers ever knew how to write distributed systems. It sounds like the Weblogic guys did though.

Zanfa 2y ago

> I do not know what was the reason to get rid of session cookies. Maybe the fear of GDPR violations Just to clarify, GDPR has nothing to do with cookies. GDPR applies exactly the same whether you use cookies, JWTs in local or session storage, some magic session id tacked at the end of every URL or device fingerprinting.

mbmjertan 2y ago
I am not surprised. A lot of people conflate GDPR with the well-intentioned but misdirected cookie directive. A lot of people blame the EU for “forcing cookie banners onto the web”, while the GDPR solely demands that you ask for consent before storing data that’s outside of your core functional needs to operate the app/website. The UX of those dialogs is largely a dark pattern because the law did not demand implementation details, yet people blame GDPR because businesses designed them to be a nightmare to use. Yet people applaud for App Tracking Transparency dialogs. It’s ironic how the GDPR is painted as a villain.
- Propelloni 2y ago
  > The UX of those dialogs is largely a dark pattern because the law did not demand implementation details, yet people blame GDPR because businesses designed them to be a nightmare to use. Yet people applaud for App Tracking Transparency dialogs. True, it does not mandate specific implementation details but in Recital 32 of the GDPR [1], it demands "request[s] must be clear, concise and not unnecessarily disruptive to the use of the service [...]" which is mostly not given with dark pattern implementations. [1] https://gdpr.eu/Recital-32-Conditions-for-consent/ https://gdpr.eu/Recital-32-Conditions-for-consent/
- Zanfa 2y ago
  > The UX of those dialogs is largely a dark pattern because the law did not demand implementation details, yet people blame GDPR because businesses designed them to be a nightmare to use. IMO the law was clear enough as highlighted in the sibling comment. It is poor enforcement that's been a major issue. If a company registered in country A flouts GPDR, even in country B, there's nothing country B can do, other than delegate to country A's data protection / privacy authority. If country A then drags their feet and takes no action, we arrive at the current situation.

bfung 2y ago

As an older coder, past my 40s, the industry hasn’t forgotten, it’s just moved on. Distributed transactions across many microservice is too inefficient and complex to deal with. DT is fine if you don’t have microservices, scaling out quickly is hard otherwise. Session cookies likewise ~ how does authN and authZ work through each microservice without overloading a central service? JWTs do decently. Don’t use microservices? That’s a different debate.

coldtea 2y ago
>Distributed transactions across many microservice is too inefficient and complex to deal with. DT is fine if you don’t have microservices, scaling out quickly is hard otherwise. Perhaps microservices were the wrong idea then... Added complexity and splitting what is still conceptually a single coordinated operation. >Don’t use microservices? That’s a different debate If it's the proper debate though, we should get to it - not just ignore that part, and say "we moved on", as if we improved things...
- nejsjsjsbsb 2y ago
  There is no we: everyone does it different. The term engineering that we stole from engineers implies making pragmatic decisions based on cost, complexity and requirements. Honestly I see the erring on the side of the traditional more than I do the extavagent in real life.

bingo-bongo 2y ago

> There is clearly a failure of engineering leadership. I am still puzzled why. I personally believe it’s lack of good engineering leadership and it’s only getting worse at this point. I’ve experienced a fair share of technical leaders without enough technical background and/or experience - people/leadership skills is equally important imho, but people with both are hard to find (scarce resource) and it seems like it’s often the tech side that gets compromised. I think one of the reasons is the IT industry is simply growing too fast, meaning we have a very small pool of people with many years of experience and a very large pool of people with less experience (compared to other industries). But we do need technical leaders, hence the compromise (need?) to pick people with less experience. Unfortunately.

nopassrecover 2y ago
As a rough generality, being good at something, like proper good at it, is incompatible with the basic forces of how modern organisations work. By this I mean the systems of reward, power, decision-making. That doesn’t mean all organisations work this way (mythically, startups of old didn’t), nor that some leaders can’t manage this tension, but tension it is which means while these leaders will often achieve “better” outcomes (that is, “more good” outcomes with relevance to the area of expertise or craft they’re good at, often but not always with more empathy and better working conditions for those delivering), they’ll also encounter more barriers to progressing to and maintaining positions of power, face greater scrutiny, probably be confused why the organisation around them isn’t understanding or valuing their capability (and spend a lot of time translating to frames they do understand and value), and ultimately greater burnout.
- dasil003 2y ago
  I think the challenge is largely a matter of scale. Once you have thousands or tens of thousands of people, communication becomes by far the dominant factor in outcomes. You can set up different structures and cultural norms to try to nudge things in the right direction, but there is no org structure that can solve this because local details always matter. The trick is understanding which details matter and why. Ultimately I think this depends on management competence and judgement. I also think IC leadership is a critical counterweight to the distortions of empire building that incentivize creating messes. And finally as a competent individual you need the maturity to recognize the difference between unavoidable but tolerable organizational dysfunction, and broken leadership where its impossible to do good work, and hence time to cut bait and leave.

orf 2y ago

> The Weblogic servers were configured to enable distributed transactions, so … there was a high degree of assurance that there will be no data corruption nor race conditions. > we have forgotten how to make distributed apps Have you, really? Did you ever know? It sounds like you just: - used a framework (I hope the “high assurance” bit is a joke…) - then forgot to configure it correctly for a new deployment environment. Honestly, “Engineering excellence” and “we build things with Weblogic distributed transactions” are two things that are not commonly put together.

sam_lowry_ 2y ago
> “high assurance” bit is a joke… OP here. It is not, Weblogic distributed transactions are using two-phase commits under the hood. From the point of view of contemporary Computer Science, two-phase commits give up Availability in the CAP theorem. Deadlocks may still happen. The issue with moving from Weblogic to Kubernetes is that previously, Weblogic enforced consistency and prevented partitioning. With Kubernetes, this responsibility moved from the Weblogic to application developers. Were they prepared or empowered to take over? I think not all of them and not everywhere.
sriram_malhar 2y ago
Ouch! I wrote much of the Weblogic server's distributed transactions framework back in the day. Forget EJB (which too I wrote :(, but in my defense it was forced on us by IBM and Oracle, and I personally hated it). The JTA bit was a thin sliver over the various db and messaging product vendors' XA drivers, which differed in important and annoying ways. Some were not thread-safe (SQLServer), some drivers' connections had to be pinned to the same thread (Informix) etc. As a user, if you had to have distributed transactions, you would have done worse than Weblogic, methinks.
- orf 2y ago
  Sorry! I didn’t mean to throw shade on your work. What I mean is that being able to turn a key in a car ignition doesn’t make one a car mechanic.

apples_oranges 2y ago

We try new things, keep what is useful and discard what is not. That is normal, why complain, just do what is best for your problem.

Cthulhu_ 2y ago
They complain because they discarded what is useful, breaking solved problems and needing to spend a lot of resources on working around that instead of solving the actual problem. But this is a recurring problem in software development, people spend all their energy on setup and innovation, and relatively little on the actual value.

szundi 2y ago

These are the new rockstar dev 20s devs who don’t know these and invent new ways - probably

andrewstuart 2y ago

Companies have outsourced their thinking to Amazon Web Services. Software developers and architects when faced with a problem, challenge, question about how to do things, simply look up the answer in Amazon Web Services documentation.

rednafi 2y ago

JWT is one of the worst things that came out of the JS frontend ecosystem and spread everywhere. It made working with services so much more cumbersome in the name of security. Then people started using it to carry contextual information, and now it’s pretty common to see ginormous tokens being sent out in every S2S call. Also, everyone loves working with obnoxiously short token refresh time.

donatj 2y ago
The number of times I have had to remind a developer that the contents of the JWT are readable is nuts. Way too often they want to treat it like a general session store and just toss any old state in there regardless of if the end user should be able to see the value.
- feoren 2y ago
  The contents of a session cookie are also readable...
  - dasil003 2y ago
    I think he's talking about a server-side session store (or perhaps an encrypted cookie payload)

burgerrito 2y ago

> Screen readers and many kinds of web accessibility are barely useable, all that... because we have forgotten about session cookies. What did the author meant by this? In what way that accessibility and session cookie are related?

donatj 2y ago
My presumption would be a natively reliable back button. / navigation in general that doesn't end up accidentally losing your session

tpm 2y ago

> application server that synchronized state among instances Huge sessions that move frequently (even if the original developers understand this and are disciplined enough, the juniors that continue development of the app are not, so the session size grows). This eats all the available memory and is slow. So it's better to go if not completely stateless then at least restrict the session to a viable minimum.

roenxi 2y ago

There is a management principle here that the tech world doesn't seem to have internalised yet. It is linked to the basic problem that we can't measure programmer productivity. Software tends to be modularised based on a company's management structure. What the components do tends to reflect the manager. When the manager changes, the software either starts to change too or succumbs to bitrot. It is pretty normal for tech companies to start listing after the original founders move on - even a company like Google or Microsoft with money and technically strong individual employees starts to mean regress as new managers come in who have a different and murkier vision than the founders. With luck the transition can be from excellence to a different form of excellence, but the basic strategy people seem to have that management is to be encoded in the org structure and bureaucratic processes doesn't seem to work at preserving high-performing tech companies. It depends on specific people in key leadership positions. Because if they get swapped out there is no way to measure the productivity change less effective managers foist on developers until the company has notably mean regressed years later. I'd bet something like this happened here. A team lead or someone was swapped out and replaced with someone who thought differently.

julik 2y ago
Or, what happens sometimes, a "team lead or someone" was replaced with a pack of freshly appointed team leads, with nobody being positioned to "break ties" with them and with an explicit ban on any sane engineering guidance "because we don't want to depend on one person". Then those team leads would try to drive their teams and efforts in alignment with the ways they saw familiar or acceptable, and with zero interest for the "big picture" - they would be focused on the survival of their position and their team only. Fiefdoms would emerge, and every little such fiefdom would be pulling the rug its way. With disastrous consequences for all of security, end user convenience, stability, resilience and malleability of the system.
- deltaburnt 2y ago
  The zero interest in big picture and fiefdoms hits home pretty hard. Even if a subgroup wants to put emphasis on the big picture that's just one more set of hands on the rug. Suddenly you're spending more time arguing and fighting political battles instead of building great stuff. You can win some battles, but you have to have amazing persistence to not burn out or retreat to your subgroup mentality after a while. I really don't care if I disagree with top level technical leadership. Having no technical leadership is even worse.

arkh 2y ago

Idea for your next article: progressive enhancement. I can't wait for people to discover it again.

sam_lowry_ 2y ago
Hah. Back in 2011 my team built a news website with adaptive delivery. It loaded a small html page with a javascript that checked the screen size and user agent, then based on whether the user was on a phone, a tablet or a desktop, downloaded and displayed the content crafted for that particular device. It then left a cookie to avoid the extra round-trip for returning visitors. Nowadays people tend to adapt the design to devices with CSS frameworks and flexbox layout, but this does not always reduce traffic and CPU time for low-powered devices. While our engineering feat was adorable and I praised the team for the achievement, this architecture did not last. The editorial team did not want to maintain essentially 3 different content layouts daily, the marketing team was not willing to compromise on ads on smaller screens. None was happy except the readers.

julik 2y ago

We haven't forgotten anything - rather we were forced to remain silent. https://blog.julik.nl/2024/03/those-people-who-say-no https://blog.julik.nl/2024/03/those-people-who-say-no I may do a writeup on how the mentioned things are very indicative of a certain org failure, since I've seen something very similar first hand.

DavidPiper 2y ago

> Screen readers and many kinds of web accessibility are barely useable, all that... because we have forgotten about session cookies. No I feel like screen readers and many kinds of web accessibility are barely useable because we forgot about screen readers and web accessibility.

jalk 2y ago

The browser session concept has “eroded” over time. Many, if not most, laptop users rarely closer all browser windows and hence sessions can last months. Haven’t checked but I wouldn’t be surprised if session cookies survive a browser update, started from the menu at

Ekaros 2y ago
It does. Google is good example. I have fully closed my computer for a while and restarted it and session is still there. It is amazing just how long they can last if you regularly use it.
- jalk 2y ago
  I believe that google login cookies, are persistent cookies with a longish max-age/expires value, so that is not surprising, and hence why you have to use google periodically to "refresh" the cookies. Here is what MDN[1] says about session cookies: > Session cookies — cookies without a Max-Age or Expires attribute – are deleted when the current session ends. The browser defines when the "current session" ends, and some browsers use session restoring when restarting. This can cause session cookies to last indefinitely. I was unaware of the "session restoring" point. This has to be considered if wanting to "unforget" the use of session cookies. [1] https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies (edit for layout)

throwaway_2494 2y ago

I share the author's frustration with this trend that _everything_ be a JSON object. Just recently I had some colleagues create a 200Mb JSON blob representing data records with the goal of querying the data in various ways. I instead loaded it into a SQL database and wrote a few queries which quickly got the job done. Also I totally agree that people have forgotten how to stream data via HTTP now, coming up with all sorts of crappy handcrafted approaches, often involving JSON. I've seen many sorry examples of this too. See: https://jargonfile.johnswitzerland.com/stone-knives-and-bearskins.html https://jargonfile.johnswitzerland.com/stone-knives-and-bear...

veqq 2y ago

Similar in spirit: https://rakhim.org/its-all-just-fashion-shows/ https://rakhim.org/its-all-just-fashion-shows/

deleted 2y ago

[deleted]

GuB-42 2y ago

> Access denied > You are not authorized to access this page. It seems we have forgotten the article. But not the Internet Archive https://web.archive.org/web/20250130030201/http://mikhailian.mova.org/node/291 https://web.archive.org/web/20250130030201/http://mikhailian...