Hacker News Reader

Comment by burningChrome | Hacker News Reader

>> they would start to experience problems, like seeing eachothers data and stuff.

Wait, what?

I'm going to need some explanation or story time about how this happened.

The idea was that you would visit participating merchants, spend money there and they would give you codes on stickers that they generated from our site and then the customers would use those codes on the site with purchase amount to get sayacash. One problem we had was that the codes we generated turned out to be invalid because... we didnt know why. We generated the codes, but they werent in the database. Where did they go? The customers would try to enter them, and be told that they are invalid, or go to their dashboard and see stuff that wasnt theirs because there was only one session object for the entire app.

It was a huge mess. At some point we made a video that would explain how the site was to be used. You can find it here: https://www.youtube.com/@sayagle.

Every single person in every video was employed by this company. The tea place in the first video was owned by the founder. :)

Wow in the first video the man behind the camera refers to customers as clowns. Acts as if the guy he grabbed is stupid and not capable to enter a code on the web page. So weird.

I just noticed that the video about donating to charities ends with the narrator trailing off with "I don't know what I should say".

I am surprised we decided to upload those videos. It might have been during the time when people weren't being paid regularly

It sounds like this was a terrible, terrible, terrible, terrible, terrible company. I suppose it's telling that a Google search mostly turns up your story about the company, and an assortment of random mentions from a decade and a half ago. How did Sayagle die in the end?

ran out of money

My employer let me pick my own gift from a website with countless products. I visited regularly to progress looking over the gifts. The small print said you had something like 7 days to chose. After 2 or 3 weeks I finally made a choice, it congratulated me, deducted the points from my balance and provided tracking information. Then nothing happened. I could even log in again and spend the remaining points but nothing shipped.

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.

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.

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.

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”.

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

There are many ways to shoot yourself in the foot.

Reply on news.ycombinator.com