Very Stupid Javascript Question

A place to discuss the implementation and style of computer programs.

Moderators: phlip, Moderators General, Prelates

User avatar
Archgeek
Posts: 200
Joined: Wed May 02, 2007 6:00 am UTC
Location: Central US
Contact:

Very Stupid Javascript Question

Postby Archgeek » Mon Oct 12, 2015 4:16 pm UTC

Just what does a browser (IE 10, for instance) actually do under the hood when a user disables javascript?
Does it just disable its JS interpreter, preventing it from loading scripts in future requests, or does it bother stopping currently running scripts and their listeners?
I inquire in part due to a very persistent fencepost error in a little AJAX JS support detection script I've got (purely to support a friendlier error message an otherwise agnostic application).

Relatedly, is it a bad idea to send AJAX on beforeunload? My connection slowly ground to a halt while testing this, which was only resolved by logging out/in to windows. However I'm not sure if it was Fiddler's fault or something I was doing was leaving open sockets scattered around until it ran out.

Here's the code in question, in case anyone wants to see it:
Spoiler:

Code: Select all

if(document.addEventListener){
   window.addEventListener("beforeunload", JSassert, false);
}else{
   if(window.attachEvent) //for older IE versions
      window.attachEvent("onbeforeunload", JSassert);
   else alert("what, what went wrong here?");//*/
}


function JSassert(){
   //attempt to create XMLHttp object
   var xhr = false;
   if (window.ActiveXObject) { // IE
       try {
          //yeah, it's this one
         xhr = new ActiveXObject("Msxml2.XMLHTTP");
       } catch (e) {
         try {
           xhr = new ActiveXObject("Microsoft.XMLHTTP");
           alert('not MSXML2 ActiveX');
         } catch (e) {
            alert('not Microsoft ActiveX');
         }
       }
     }
     if (!xhr) {
       alert('Cannot create XMLHTTP instance');
       return false;
     }
    
     //send JS support assertion
     xhr.open('GET', location.pathname + '?JSsupport=true',true);
     xhr.send();
}
"That big tube down the side was officially called a "systems tunnel", which is aerospace contractor speak for "big tube down the side."

User avatar
Xanthir
My HERO!!!
Posts: 5327
Joined: Tue Feb 20, 2007 12:49 am UTC
Location: The Googleplex
Contact:

Re: Very Stupid Javascript Question

Postby Xanthir » Mon Oct 12, 2015 6:51 pm UTC

I *suspect* it just turns off the interpreter for future pages, but I'm not sure.

Using XHR on beforeunload isn't a great idea, because there's no guarantee that the page won't be killed before the XHR completes. (That might be the problem you're seeing.) There's one trick (that all browsers support, and which is now officially codified in specs because otherwise lots of sites would break) that helps out here - a browser will *not* cancel an *<img>* request, even if it tears down the rest of the page. So if you need to send a page-is-going-away ping, create an <img> element and set its src to the XHR target. This only allows GET requests, but that's fine for most purposes.
(defun fibs (n &optional (a 1) (b 1)) (take n (unfold '+ a b)))

User avatar
Archgeek
Posts: 200
Joined: Wed May 02, 2007 6:00 am UTC
Location: Central US
Contact:

Re: Very Stupid Javascript Question

Postby Archgeek » Mon Oct 12, 2015 7:18 pm UTC

Xanthir wrote:I *suspect* it just turns off the interpreter for future pages, but I'm not sure.

Using XHR on beforeunload isn't a great idea, because there's no guarantee that the page won't be killed before the XHR completes.


Drat, 'sounds like I may be stuck in fencepost land.

That makes sense, though I've already changed it back to DOMContentLoaded, as beforeunload was causing a storm of false negatives in new tabs...which I really should've seen coming.
"That big tube down the side was officially called a "systems tunnel", which is aerospace contractor speak for "big tube down the side."

Tub
Posts: 401
Joined: Wed Jul 27, 2011 3:13 pm UTC

Re: Very Stupid Javascript Question

Postby Tub » Mon Oct 12, 2015 8:45 pm UTC

Archgeek wrote:Just what does a browser (IE 10, for instance) actually do under the hood when a user disables javascript?
Does it just disable its JS interpreter, preventing it from loading scripts in future requests, or does it bother stopping currently running scripts and their listeners?

Depends on the browser. Don't rely on any particular behaviour.

Archgeek wrote:Relatedly, is it a bad idea to send AJAX on beforeunload?

yes it is. It is a bad idea to even touch beforeunload unless you really, really need to. Unsaved form entries are a valid reason, JS detection most certainly isn't.


What exactly are you trying to do, anyway? Notify the server if javascript is supported on the client? Why? What is the server going to do about it? Are you ok with the fact that a shaky internet connection at the right moment would lead the server to wrongly believe that JS is disabled? Are you ok with the race condition that occurs when the user clicks somewhere before the AJAX request succeeds?

What you're saying sounds like you're going down the wrong path for all the wrong reasons. Why don't you go back a step and tell us what you're doing?


Code: Select all

if(document.addEventListener){
   window.addEventListener("beforeunload", JSassert, false);

Checking for the property in document, but calling it on window? Is there a reason for that?

Code: Select all

   else alert("what, what went wrong here?");//*/

Somewhere, someone with a weird browser is going to be surprised by this. I'd suggest getting in the habit of using console.log() instead of alert() for debugging.

Code: Select all

if (window.ActiveXObject) { // IE

Uh, you're only checking for the old IE implementations. Always try the standard version first, only if that fails go for the fallbacks. Remember that ActiveX has officially gone the way of the Dodo and won't work in Edge any more.

User avatar
Archgeek
Posts: 200
Joined: Wed May 02, 2007 6:00 am UTC
Location: Central US
Contact:

Re: Very Stupid Javascript Question

Postby Archgeek » Mon Oct 12, 2015 9:28 pm UTC

Tub wrote:
Archgeek wrote:Just what does a browser (IE 10, for instance) actually do under the hood when a user disables javascript?
Does it just disable its JS interpreter, preventing it from loading scripts in future requests, or does it bother stopping currently running scripts and their listeners?

Depends on the browser. Don't rely on any particular behaviour.

Oh, little doubt, but I'm officially just told to support IE9 and 10.

Tub wrote:
Archgeek wrote:Relatedly, is it a bad idea to send AJAX on beforeunload?

yes it is. It is a bad idea to even touch beforeunload unless you really, really need to. Unsaved form entries are a valid reason, JS detection most certainly isn't.

Yup, I also found it broke detection for new tabs, so I changed it back to DOMContentLoaded.

Tub wrote:What exactly are you trying to do, anyway? Notify the server if javascript is supported on the client? Why? What is the server going to do about it? Are you ok with the fact that a shaky internet connection at the right moment would lead the server to wrongly believe that JS is disabled? Are you ok with the race condition that occurs when the user clicks somewhere before the AJAX request succeeds?

Yes I am, with the intent of slightly modifying a certain error message to reflect that the user has greater agency in resolving it than if they did not support javascript currently (namely closing a one or a few tabs to resolve an otherwise unrecoverable state of having run up against a given maximum and requesting another). Yup, it's otherwise JS-agnostic so they'd just be told to save their work and re-open their browser if they really required a new tab.

Tub wrote:What you're saying sounds like you're going down the wrong path for all the wrong reasons. Why don't you go back a step and tell us what you're doing?
Yeah, this is just for things wherein the abilities brought by a given script might change a message delivered to the user. All the real functionality avoids actually requiring JS in any way.

Tub wrote:Checking for the property in document, but calling it on window? Is there a reason for that?

For some reason calling in document was failing silently, whereas window worked. It seems to've been a conflict with another script that actually needs beforeunload (probable tab closure detection, filtering refreshes, link clicks, form submits and other valid navigations) that was being dumb and using window.onbeforeunload = instead of an event listener.

Tub wrote:

Code: Select all

   else alert("what, what went wrong here?");//*/

Somewhere, someone with a weird browser is going to be surprised by this. I'd suggest getting in the habit of using console.log() instead of alert() for debugging.

HAH! You've actually revealed a typo, there. That was supposed to say "wait, what when wrong here?". Needless to say, that'll get logged or just plain ommitted in production.

Tub wrote:

Code: Select all

if (window.ActiveXObject) { // IE

Uh, you're only checking for the old IE implementations. Always try the standard version first, only if that fails go for the fallbacks. Remember that ActiveX has officially gone the way of the Dodo and won't work in Edge any more.

Glad to hear it. Sadly, supporting IE 9+.
"That big tube down the side was officially called a "systems tunnel", which is aerospace contractor speak for "big tube down the side."

douglasm
Posts: 630
Joined: Mon Apr 21, 2008 4:53 am UTC

Re: Very Stupid Javascript Question

Postby douglasm » Mon Oct 12, 2015 11:42 pm UTC

Archgeek wrote:Needless to say, that'll get logged or just plain ommitted in production.

Assuming you remember to do that before submitting it. Forgetting to remove debugging code is a common cause of publicly visible programming goofs.

User avatar
chridd
Has a vermicelli title
Posts: 829
Joined: Tue Aug 19, 2008 10:07 am UTC
Location: ...Earth, I guess?
Contact:

Re: Very Stupid Javascript Question

Postby chridd » Tue Oct 13, 2015 7:40 am UTC

Archgeek wrote:
Tub wrote:What exactly are you trying to do, anyway? Notify the server if javascript is supported on the client? Why? What is the server going to do about it? Are you ok with the fact that a shaky internet connection at the right moment would lead the server to wrongly believe that JS is disabled? Are you ok with the race condition that occurs when the user clicks somewhere before the AJAX request succeeds?

Yes I am, with the intent of slightly modifying a certain error message to reflect that the user has greater agency in resolving it than if they did not support javascript currently (namely closing a one or a few tabs to resolve an otherwise unrecoverable state of having run up against a given maximum and requesting another). Yup, it's otherwise JS-agnostic so they'd just be told to save their work and re-open their browser if they really required a new tab.
Like I mentioned here, the server doesn't need to know whether the browser has JavaScript enabled to do this; you can change the error message from JavaScript. Demonstration.

Archgeek wrote:Just what does a browser (IE 10, for instance) actually do under the hood when a user disables javascript?
Does it just disable its JS interpreter, preventing it from loading scripts in future requests, or does it bother stopping currently running scripts and their listeners?
Try it and see. Make a simple page with a simple event handler (say, show an alert when you click something), load it with JavaScript enabled, turn off JavaScript, and see if the event handler still fires.
~ chri d. d. /tʃɹɪ.di.di/ (Phonotactics, schmphonotactics) · she(?)(?(?)(?))(?(?(?))(?))(?) · Forum game scores
mittfh wrote:I wish this post was very quotable...
chridd (on Discord) wrote:
Dummy wrote:Sorry You're Gay Dads
SYG'D
marionic (on Discord) wrote:sleep in grave

Tub
Posts: 401
Joined: Wed Jul 27, 2011 3:13 pm UTC

Re: Very Stupid Javascript Question

Postby Tub » Tue Oct 13, 2015 9:43 am UTC

Archgeek wrote:Yes I am, with the intent of slightly modifying a certain error message to reflect that the user has greater agency in resolving it than if they did not support javascript currently (namely closing a one or a few tabs to resolve an otherwise unrecoverable state of having run up against a given maximum and requesting another). Yup, it's otherwise JS-agnostic so they'd just be told to save their work and re-open their browser if they really required a new tab.

And it's not feasible to remove whatever limitation you have from the server side?

What you're trying to do will break horribly if
a) a ajax request gets lost somewhere
b) the browser crashes or otherwise loses the onunload events
c) someone dares to open your website on two computers at the same time, possibly even with two differently configured browsers
d) a myriad of other ways

Neither tab detection nor realtime JS detection will work reliably outside of testing environments. If all you care about is a simple error message, you're asking for way more headaches than the problem is worth.

Archgeek wrote:
Tub wrote:

Code: Select all

if (window.ActiveXObject) { // IE

Uh, you're only checking for the old IE implementations. Always try the standard version first, only if that fails go for the fallbacks. Remember that ActiveX has officially gone the way of the Dodo and won't work in Edge any more.

Glad to hear it. Sadly, supporting IE 9+.

IE9+ supports the standard version. If that's all you care about, you gain nothing by using the obsolete IE6 way. You don't need to check for addEventListener, either. It'll be there.

I don't get why you're very restrictive in the supported browsers, but seem to invest a lot of time in the <1% of users with JS disabled. The intersection between IE users and those technically savvy enough to disable JS seems.. small.

User avatar
ucim
Posts: 6555
Joined: Fri Sep 28, 2012 3:23 pm UTC
Location: The One True Thread

Re: Very Stupid Javascript Question

Postby ucim » Tue Oct 13, 2015 2:03 pm UTC

Tub wrote:I don't get why you're very restrictive in the supported browsers, but seem to invest a lot of time in the <1% of users with JS disabled.
I'm not the OP, but in my case it is to encourage people to disable javascript, and to encourage web developers to not require that disease in order to function.

Way too much of the internet is substituting javascript for ordinary HTML, forcing users to turn javascript on, enabling more intrusive monitoring of those users.

It's like sending out .exe files by email in the normal course of business, that unpack into a text file. It trains users the wrong way, and we'll all eat it in the end.

Jose
Order of the Sillies, Honoris Causam - bestowed by charlie_grumbles on NP 859 * OTTscar winner: Wordsmith - bestowed by yappobiscuts and the OTT on NP 1832 * Ecclesiastical Calendar of the Order of the Holy Contradiction * Please help addams if you can. She needs all of us.

User avatar
Archgeek
Posts: 200
Joined: Wed May 02, 2007 6:00 am UTC
Location: Central US
Contact:

Re: Very Stupid Javascript Question

Postby Archgeek » Tue Oct 13, 2015 2:54 pm UTC

chridd wrote:Like I mentioned here, the server doesn't need to know whether the browser has JavaScript enabled to do this; you can change the error message from JavaScript. Demonstration.

Heh, I had that realization just before going home yesterday -- instead of bothering with this, I could just check the DOM for my organization's little message box and check that for the sans-JS error, and just replace the text. Unless of course someone like my supervisor's supervisor insists on a dang JS detection module and can't be dissuaded (in which case they'll just have to deal with the dumb fencepost error).

edit: just actually clicked through that link -- Oh-hO~, well well, looky what I forgot about from half a year ago. 'Would've saved my butt some dang ol' trouble if I'd recalled that now that said project is indeed out of mothballs.

chridd wrote:Try it and see. Make a simple page with a simple event handler (say, show an alert when you click something), load it with JavaScript enabled, turn off JavaScript, and see if the event handler still fires.

I've already done mostly the same watching my AJAX requests in Fiddler, but I wasn't sure my results were representative, since there are enough GPOs on the box that its behaviour can be downright stochastic.
Last edited by Archgeek on Tue Oct 13, 2015 3:44 pm UTC, edited 1 time in total.
"That big tube down the side was officially called a "systems tunnel", which is aerospace contractor speak for "big tube down the side."

User avatar
Archgeek
Posts: 200
Joined: Wed May 02, 2007 6:00 am UTC
Location: Central US
Contact:

Re: Very Stupid Javascript Question

Postby Archgeek » Tue Oct 13, 2015 3:31 pm UTC

Tub wrote:And it's not feasible to remove whatever limitation you have from the server side?

Nope, the tab limit is intentional, to reduce memory usage by crazy users possibly opening a crapload of the same webapp. They're deprecated and recycled where possible, but if they all have data and have deprecated via a probable tab-closure event, we run into this error. It is a bit of an edge-case, though.

Tub wrote:What you're trying to do will break horribly if
a) a ajax request gets lost somewhere
b) the browser crashes or otherwise loses the onunload events
c) someone dares to open your website on two computers at the same time, possibly even with two differently configured browsers
d) a myriad of other ways

Most of which aren't really problems.
a) a tab doesn't deprecate, reducing the effective max by one, not an issue.
b) very much not a problem, as they'll come back with a whole new session.
c) also fine, two separate sessions with their own sets of tabs are free to run under the same user ID. The whole point of this tab malarkey was to divide the session into little tab namespaces to prevent webapp forms using the session under the same variable names from stomping on eachother's data. If one browser's got JS and the other doesn't, then one recycles closed tabs while the other does not. (I'll also note that if a closed tab is re-opened, it's taken off the deprecated queue, so data's rarely lost.)

Tub wrote:Neither tab detection nor realtime JS detection will work reliably outside of testing environments. If all you care about is a simple error message, you're asking for way more headaches than the problem is worth.

Yeah, I realized checking the DOM for the error in question and replacing the text would be easier and more reliable.

Tub wrote:IE9+ supports the standard version. If that's all you care about, you gain nothing by using the obsolete IE6 way. You don't need to check for addEventListener, either. It'll be there.

I don't get why you're very restrictive in the supported browsers, but seem to invest a lot of time in the <1% of users with JS disabled. The intersection between IE users and those technically savvy enough to disable JS seems.. small.

Actually I went ahead and put the standard version in there, leaving the older stuff in as fallback in case some clod is still secretly using IE6 on an XP box they shouldn't have.

The JS tomfoolery is because there actually is something else we have to support, Blynx -- Lynx for the blind. It lacks JS support and a lot of accesiblity packages make use of it, since it works really well with screenreaders. We've got a mandate to keep our stuff accessible, so nothing can rely utterly on JS. Blind users are regsistered in a database somewhere, so we can just look them up and give them a very large max tabs or remove their limit entirely.

edit: removed a rogue conjunction
edit2: where'd that 'a' come from? I needed an 'e', there.
Last edited by Archgeek on Thu Oct 15, 2015 10:17 pm UTC, edited 1 time in total.
"That big tube down the side was officially called a "systems tunnel", which is aerospace contractor speak for "big tube down the side."

DaveInsurgent
Posts: 207
Joined: Thu May 19, 2011 4:28 pm UTC
Location: Waterloo, Ontario

Re: Very Stupid Javascript Question

Postby DaveInsurgent » Thu Oct 15, 2015 8:42 pm UTC

ucim wrote:
Tub wrote:I don't get why you're very restrictive in the supported browsers, but seem to invest a lot of time in the <1% of users with JS disabled.
I'm not the OP, but in my case it is to encourage people to disable javascript, and to encourage web developers to not require that disease in order to function.

Way too much of the internet is substituting javascript for ordinary HTML, forcing users to turn javascript on, enabling more intrusive monitoring of those users.

It's like sending out .exe files by email in the normal course of business, that unpack into a text file. It trains users the wrong way, and we'll all eat it in the end.

Jose


This is literally the most futile thing I've seen anyone trying to do in a while. The Web is a computing platform. You've lost; anyone you're managing to confuse with this nonsense is just being held back. A much harder, but real goal, is teaching people to be aware. "Don't use JavaScript" is not awareness. It's neo-luddism.

Most of which aren't really problems.
a) a tab doesn't deprecate, reducing the effective max by one, not an issue.
b) very much not a problem, as they'll come back with a whole new session.
c) also fine, two separate sessions with their own sets of tabs are free to run under the same user ID. The whole point of this tab malarkey was to divide the session into little tab namespaces to prevent webapp forms using the session under the same variable names from stomping on eachother's data. If one browser's got JS and the other doesn't, then one recycles closed tabs while the other does not. (I'll also note that if a closed tab is re-opened, it's taken off the deprecated queue, so data's rarely lost.)


Everything you're doing is terrible oh my god stop. You're either just coming up with the worlds worst concurrent version control system or you've over-engineering yourself in to a blind alley. Stoooop.

User avatar
Archgeek
Posts: 200
Joined: Wed May 02, 2007 6:00 am UTC
Location: Central US
Contact:

Re: Very Stupid Javascript Question

Postby Archgeek » Thu Oct 15, 2015 10:16 pm UTC

DaveInsurgent wrote:
Most of which aren't really problems.
a) a tab doesn't deprecate, reducing the effective max by one, not an issue.
b) very much not a problem, as they'll come back with a whole new session.
c) also fine, two separate sessions with their own sets of tabs are free to run under the same user ID. The whole point of this tab malarkey was to divide the session into little tab namespaces to prevent webapp forms using the session under the same variable names from stomping on eachother's data. If one browser's got JS and the other doesn't, then one recycles closed tabs while the other does not. (I'll also note that if a closed tab is re-opened, it's taken off the deprecated queue, so data's rarely lost.)

Everything you're doing is terrible oh my god stop. You're either just coming up with the worlds worst concurrent version control system or you've over-engineering yourself in to a blind alley. Stoooop.

HeHEehAHaHaehahahahahahaHeeee...oh dear, I've no idea why that made me laugh so much, there. I guess I read that in the voice of Abby Howard talking to her friend Catherine Spoons? Odd.

Anyway, it's no concurrent VCS, that would be a spiral of madness on a web platform. It's just a session (read: $_SESSION) management class that lets web application developers have $_SESSION functionality without worrying about having their variables stomp on/get stomped on by those of another application at run-time. It's JS agnostic because it largely doesn't need it, there's a configurable max tabs setting because I was told to add one, my little JS tab closure detection system and deprecation queue are there because a solution was requested to deal with "orphaned" tabs running up the count, and the whole thing exists because the Zend Framework 2 session manager is a thing Azathoth has nightmares about.
I see now that not only is JS detection dumb (which I knew), but it's also doomed (and there's a less stupid way). Unfortunately I was asked to make a general-purpose JS-detection solution, but hopefully I've got enough evidence to talk people down on that front at this point.

Now, those explanations aside, you've made me curious -- what am I over-engineering and in what manner? Given the choice, I would like to simplify this thing as much as I can before it sees the quivering horrors of production.
"That big tube down the side was officially called a "systems tunnel", which is aerospace contractor speak for "big tube down the side."

DaveInsurgent
Posts: 207
Joined: Thu May 19, 2011 4:28 pm UTC
Location: Waterloo, Ontario

Re: Very Stupid Javascript Question

Postby DaveInsurgent » Fri Oct 16, 2015 3:22 am UTC

Archgeek wrote:
DaveInsurgent wrote:
Most of which aren't really problems.
a) a tab doesn't deprecate, reducing the effective max by one, not an issue.
b) very much not a problem, as they'll come back with a whole new session.
c) also fine, two separate sessions with their own sets of tabs are free to run under the same user ID. The whole point of this tab malarkey was to divide the session into little tab namespaces to prevent webapp forms using the session under the same variable names from stomping on eachother's data. If one browser's got JS and the other doesn't, then one recycles closed tabs while the other does not. (I'll also note that if a closed tab is re-opened, it's taken off the deprecated queue, so data's rarely lost.)

Everything you're doing is terrible oh my god stop. You're either just coming up with the worlds worst concurrent version control system or you've over-engineering yourself in to a blind alley. Stoooop.

HeHEehAHaHaehahahahahahaHeeee...oh dear, I've no idea why that made me laugh so much, there. I guess I read that in the voice of Abby Howard talking to her friend Catherine Spoons? Odd.

Anyway, it's no concurrent VCS, that would be a spiral of madness on a web platform. It's just a session (read: $_SESSION) management class that lets web application developers have $_SESSION functionality without worrying about having their variables stomp on/get stomped on by those of another application at run-time. It's JS agnostic because it largely doesn't need it, there's a configurable max tabs setting because I was told to add one, my little JS tab closure detection system and deprecation queue are there because a solution was requested to deal with "orphaned" tabs running up the count, and the whole thing exists because the Zend Framework 2 session manager is a thing Azathoth has nightmares about.
I see now that not only is JS detection dumb (which I knew), but it's also doomed (and there's a less stupid way). Unfortunately I was asked to make a general-purpose JS-detection solution, but hopefully I've got enough evidence to talk people down on that front at this point.

Now, those explanations aside, you've made me curious -- what am I over-engineering and in what manner? Given the choice, I would like to simplify this thing as much as I can before it sees the quivering horrors of production.


I'll try be more friendly. Sorry.

Let's start with this: There is exactly zero reason for there to be any web application that relies on sessions and any framework or system that does so should be summarily dismissed as Broken By Design. It is almost 2016. Communication between clients and servers in the context of the web has always been intended to be stateless. In this day and age, it's actually "doable" if not easy. If you're stuck with a big system that already relies on sessions, declare it broken, do the absolute minimum you can do in order to keep it from self-destructing, and start the rearchitecture. If you're trying to actually make it easier for people to write session-oriented application tiers, please don't - it's absolutely the wrong thing to do.

User avatar
Archgeek
Posts: 200
Joined: Wed May 02, 2007 6:00 am UTC
Location: Central US
Contact:

Re: Very Stupid Javascript Question

Postby Archgeek » Fri Oct 16, 2015 3:54 pm UTC

DaveInsurgent wrote:
Now, those explanations aside, you've made me curious -- what am I over-engineering and in what manner? Given the choice, I would like to simplify this thing as much as I can before it sees the quivering horrors of production.


I'll try be more friendly. Sorry.

Let's start with this: There is exactly zero reason for there to be any web application that relies on sessions and any framework or system that does so should be summarily dismissed as Broken By Design. It is almost 2016. Communication between clients and servers in the context of the web has always been intended to be stateless. In this day and age, it's actually "doable" if not easy. If you're stuck with a big system that already relies on sessions, declare it broken, do the absolute minimum you can do in order to keep it from self-destructing, and start the rearchitecture. If you're trying to actually make it easier for people to write session-oriented application tiers, please don't - it's absolutely the wrong thing to do.

No worries, that delivery was genuinely amusing.

By and large, I agree, things shouldn't rely outright on session, or worse, be session-oriented. However, there are some older applications we support (several of which really are rather broken, design-ways) that make heavy use of it. Plus we do kinda need it for stuff like our SSO tokens and dragging user-facing error messages across redirects ("you screwed that up, let's try again" sort of stuff) without making them bookmarkable. It also gets abused for stuff like timing information, but that's just debuggery/profiling and doesn't really count.

I'm not trying to make it easier (heck, having to bother with a reference to a sub-array in $_SESSION makes it a bit harder) to abuse session, but just safer, especially for extant applications whose exhibition of the problem mentioned above was the impetus for making this thing. If we can keep some dope's old code that likes to shove its form values in $_SESSION from stomping on itself and messing up the database, all the better.
"That big tube down the side was officially called a "systems tunnel", which is aerospace contractor speak for "big tube down the side."

User avatar
ucim
Posts: 6555
Joined: Fri Sep 28, 2012 3:23 pm UTC
Location: The One True Thread

Re: Very Stupid Javascript Question

Postby ucim » Wed Nov 11, 2015 2:32 am UTC

DaveInsurgent wrote:There is exactly zero reason for there to be any web application that relies on sessions and any framework or system that does so should be summarily dismissed as Broken By Design. It is almost 2016.
I'm not sure I follow. How would you remember who's logged in without sessions or some equivalent?

Jose
Order of the Sillies, Honoris Causam - bestowed by charlie_grumbles on NP 859 * OTTscar winner: Wordsmith - bestowed by yappobiscuts and the OTT on NP 1832 * Ecclesiastical Calendar of the Order of the Holy Contradiction * Please help addams if you can. She needs all of us.

DaveInsurgent
Posts: 207
Joined: Thu May 19, 2011 4:28 pm UTC
Location: Waterloo, Ontario

Re: Very Stupid Javascript Question

Postby DaveInsurgent » Thu Nov 12, 2015 12:17 am UTC

ucim wrote:
DaveInsurgent wrote:There is exactly zero reason for there to be any web application that relies on sessions and any framework or system that does so should be summarily dismissed as Broken By Design. It is almost 2016.
I'm not sure I follow. How would you remember who's logged in without sessions or some equivalent?

Jose


HTTP Authorization header - put a JSON Web Token in it which states who the user is. This is decoded and verified on every request. Also an easy place to put the tenant ID, too, if its a multitenant application.

Edit: Can you can use a cookie if you're not doing anything fancy on the client side and you'e in a browser. It's the same thing.

User avatar
ucim
Posts: 6555
Joined: Fri Sep 28, 2012 3:23 pm UTC
Location: The One True Thread

Re: Very Stupid Javascript Question

Postby ucim » Thu Nov 12, 2015 3:55 pm UTC

DaveInsurgent wrote:HTTP Authorization header - put a JSON Web Token in it which states who the user is.
I take it this would work even if the user has disabled scripts?

Sessions are also a way to store client information (e.g. shopping cart, privilege list) on the server (using the session cookie as the key). You can do the same with JSON?

What is the advantage of JSON over sessions?

Jose
Order of the Sillies, Honoris Causam - bestowed by charlie_grumbles on NP 859 * OTTscar winner: Wordsmith - bestowed by yappobiscuts and the OTT on NP 1832 * Ecclesiastical Calendar of the Order of the Holy Contradiction * Please help addams if you can. She needs all of us.

User avatar
Archgeek
Posts: 200
Joined: Wed May 02, 2007 6:00 am UTC
Location: Central US
Contact:

Re: Very Stupid Javascript Question

Postby Archgeek » Thu Nov 12, 2015 9:48 pm UTC

ucim wrote:I take it this would work even if the user has disabled scripts?

JSON's just a clever little encoding scheme for transmiting arbitrary data structures in the form of a string. I found it to be an insanely superior option to my insane tokenization scheme I bodged up for sending server-side debug info in an AJAX reply. PHP can gleefully endcode and decode them no problem.
Sessions are also a way to store client information (e.g. shopping cart, privilege list) on the server (using the session cookie as the key). You can do the same with JSON?

Yes. He's pretty much saying to shove the session stuff into that encoding and pass it around via the AUTH header or a cookie.
What is the advantage of JSON over sessions?

I think DaveInsurgent likes it because it's more RESTful. However, I cannot rely on the user supporting cookies either (for some reason, in the browser I have to support, the session cookie ignores the preference), so I fall back to $_SESSION and giving the statelessness of the protocol a bit of a rest.
"That big tube down the side was officially called a "systems tunnel", which is aerospace contractor speak for "big tube down the side."


Return to “Coding”

Who is online

Users browsing this forum: No registered users and 7 guests