5 ms·

It's not that uncommon in some languages where you have a long running monolith (.NET, Java, etc) instead of an instance of something that spins up per request

It's not that uncommon in some languages where you have a long running monolith (.NET, Java, etc) instead of an instance of something that spins up per request (Node, PHP, etc). If someone does something silly like setting the session handler to be scoped to the monolith app rather than having a scope of a single request you end up with users seeing one another's data. It's dangerously easy to do in some frameworks.

jiggawatts 2y ago
Sadly I’ve seen this happen just recently… with new code… written by someone who has over a decade of “experience”. It’s sufficient to simply use the “static” keyword or a singleton service that should be scoped to the session. The sad thing is that the default is the happy path, you have to go out of your way to break the session scoping by “being too clever”.
smallerfish 2y ago
Stateful singletons (and/or shared classes) are _probably_ a more common blunder than session scoping.
- onion2k 2y ago
  There are many ways to shoot yourself in the foot.
mattmanser 2y ago
No, more likely someone's used global or static variables. It's got nothing to do with monoliths vs micro services. You can do the same global/static variable crap in a micro-service. Plus you didn't even need to multi thread in old school asp.net, IIS would create a new process for every request back in the day. .Net did have a notorious 'session' object, which was the cause of a lot of problems due to novice/offshore programmers, but not the symptoms described above. I'm not sure why you've targeted monoliths and .net/java, but the problems described above are usually caused by multi-thread/shared variables, which weren't a common thing to do in asp.net. You'd really have to go out of your way. I've seen some terrible .net code written by novices or poorly trained offshorers, but nothing like that. I'd be more likely to bet they rolled their own cookie or session management or jwt token manager, and I'd guess it was an early js/nodejs app before that ecosystem stabilized when people were raving about going framework free and then footgunning themselves.
- mkoryak 2y ago
  I don't think node really existed when this was made in late 2009. It was built with jsf: Java server faces. Its a bit like a more enterprisey version of GWT. Everything on the page was a huge class with lots of horrors that eventually became html css and js that you never wrote. I checked, node existed but it was a toy compared to jsf.

jiggawatts 2y ago

Sadly I’ve seen this happen just recently… with new code… written by someone who has over a decade of “experience”. It’s sufficient to simply use the “static” keyword or a singleton service that should be scoped to the session. The sad thing is that the default is the happy path, you have to go out of your way to break the session scoping by “being too clever”.

smallerfish 2y ago

Stateful singletons (and/or shared classes) are _probably_ a more common blunder than session scoping.

onion2k 2y ago
There are many ways to shoot yourself in the foot.

mattmanser 2y ago

No, more likely someone's used global or static variables. It's got nothing to do with monoliths vs micro services. You can do the same global/static variable crap in a micro-service. Plus you didn't even need to multi thread in old school asp.net, IIS would create a new process for every request back in the day. .Net did have a notorious 'session' object, which was the cause of a lot of problems due to novice/offshore programmers, but not the symptoms described above. I'm not sure why you've targeted monoliths and .net/java, but the problems described above are usually caused by multi-thread/shared variables, which weren't a common thing to do in asp.net. You'd really have to go out of your way. I've seen some terrible .net code written by novices or poorly trained offshorers, but nothing like that. I'd be more likely to bet they rolled their own cookie or session management or jwt token manager, and I'd guess it was an early js/nodejs app before that ecosystem stabilized when people were raving about going framework free and then footgunning themselves.

mkoryak 2y ago
I don't think node really existed when this was made in late 2009. It was built with jsf: Java server faces. Its a bit like a more enterprisey version of GWT. Everything on the page was a huge class with lots of horrors that eventually became html css and js that you never wrote. I checked, node existed but it was a toy compared to jsf.