Race conditions on the web

Re:Race conditions on the web by paulmd on Tuesday July 12, 2016 @11:33PM (#12083739)

I used to use a camera shopping website that had a race condition in their product listing/search functionality. Their site was quite slow, and if you tried to have more than one tab open to their site then you would get mixed-up results. The tabs might have the same content, mixed content (eg the breadcrumbs from the other tab), or sometimes nothing at all. This would occur even across a significant period of time, not just if you made the requests at the same time.

I struggle to understand how that could even have happened. Were they storing the results of the DB lookup referenced against my IP somehow?

[ Parent | on HN ]

Re:Race conditions on the web by dspillett on Wednesday July 13, 2016 @04:56AM (#12084862)

That isn't so much a race condition as session/state corruption. The designer hasn't considered that their chosen state store in this instance is not entirely private so two instances of their code can clobber each other's global state.

A common occurrence of this I've seen in many places (including some of our old code years ago) is using a cookie to store simple client-side choices that you want to persist between requests, for instance the tab that was selected when you were last on a complex page, or some other temporary preference, or as in your example breadcrumbs for navigation.

This falls over as soon as the user has two tabs/windows open because (unless the window is explicitly opened with a different session i.e. in private mode, with File/NewSession in IE, or such) the cookies (even temporary session level ones) are a shared resource. It isn't a big issue usually as more often than not it only concerns superficial UI matters (those that are "nice to have"s rather than breaking something essential), but I can imagine circumstances where the problem could open more serious problems.

[ Parent | on HN ]

Re:Race conditions on the web by flukus on Wednesday July 13, 2016 @02:37AM (#12084283)

I'm guessing a lot of them stem from using session variables and from caching. I've seen everything from an nHibernate cache being stored in the session, serializing and deserializing a huge chunk of the database on every request, to developers not being aware that the session variable they get is user specific (They access it via Session[UserId]).

Caching in particular seems to be something that's applied without much analysis, I've seen it slow down implementations more often than it sped them up.

What I'd really like is for the browser to send a tab id on every request, so we can scope variable to a tab as well as user.

[ Parent | on HN ]

Re:Race conditions on the web by robocat on Wednesday July 13, 2016 @03:37AM (#12084514)

FYI: one place to store a tab id is in the window.name variable:

* it is persistent across refreshes

* it remains even if you leave page to another domain then return to page on same tab

* it disappears if the tab is closed

* it doesn't change as you navigate back/forward

* would be most useful with xhr requests or a hidden field in form post requests.

Downsides:

* no origin security

* no obvious nice way to use with page GETs for server to know which tab a page request is from.

[ Parent | on HN ]

Re:Race conditions on the web by throwawayReply on Wednesday July 13, 2016 @03:57AM (#12084599)

SessionStorage has all of those properties:

https://developer.mozilla.org/en/docs/Web/API/Window/session...

localStorage is often used for it's persistance across closing/reopening the browser, but for times when you don't want storage to bleed across tabs or closing the browser then session storage is much better, and unlike a cookie doesn't automatically get attached to request so there aren't XSRF worries.

(You still need to be careful of XSS of course.)

[ Parent | on HN ]

Re:Race conditions on the web by flukus on Wednesday July 13, 2016 @04:05AM (#12084637)

Isn't his client side only? Xhr would work for anything ajaxy but not for a page load.

[ Parent | on HN ]

Re:Race conditions on the web by JoshTriplett on Wednesday July 13, 2016 @01:10AM (#12083997)

Lenovo's website does this: if you try to browse and customize more than one ThinkPad at a time, the site will get completely confused and start replacing the older one with the newer one, losing the older one entirely.

[ Parent | on HN ]

Re:Race conditions on the web by mh- on Tuesday July 12, 2016 @11:53PM (#12083795)

probably collecting the search results into a cache of some sort, and the key was a session ID (likely stored in a cookie.)

[ Parent | on HN ]