[CODE4LIB] Crappy AJAX (was: [CODE4LIB] Q: Discovery products and authentication (esp Summon))
On Oct 25, 2012, at 6:46 AM, Gary McGath wrote: On 10/24/12 8:58 PM, Ross Singer wrote: On Oct 24, 2012, at 6:06 PM, Gary McGath develo...@mcgath.com wrote: On 10/24/12 4:00 PM, Ross Singer wrote: On Oct 24, 2012, at 3:48 PM, Gary McGath develo...@mcgath.com wrote: Also, why wouldn't your AJAX-enabled app be prepared for such an event? Are you asking how an AJAX-enabled application can handle such cases? No, I know how an AJAX-enabled application should handle such cases, I'm saying why, if you're implementing an AJAX-enabled application, why you think this would be an issue. Because I just don't see this being an issue. This has always been a tricky thing to explain; it's not just you, if that's any consolation. Someday I'll figure out how to make it clear on the first try. The point is that if a service redirects to a login page, it assumes the browser can display the login page. Normally this is true, but only if the resource would be delivered as a web page. AJAX components are received as elements, not pages. If you like, I can go into more detail off-list. This is really too much of a side technical issue to be worth taking up a lot of space on the list. You didn't answer the question -- why would you not have some sort of check on the AJAX application (or any application, web or otherwise) to do at least minimal sanity checking on the result of an external call? In the case of something requiring authentication, if it's a well designed back-end, it should return some HTTP status other than 200; 401 or 403 would be most appropriate. I've unfortunately worked with ColdFusion in the early days before they added cfheader to allow you to change the status code so that it was something other than 200. I've also seen websites that cheat to install a 'handler' for all requests by linking to a PHP script using Apache's 404 ErrorHandler directive. This also has the side effect that search engines won't index your site at all (as they assume it's all errors) In both of these cases, I'd say the service is poorly designed if you can't easily identify a failure. You can send a login page along with your 401 status, but you *should* *not* send a 30x redirect to a login page, as then the actual status message is lost. (the content hasn't been moved ... you just want someone to go to the login page ... the HTTP specs don't forbid a Location field w/ a 40x status, although I admit I've never verified that major browsers support it) If you have something pulling in content using something AJAX-like, and it *doesn't* check the result, then the client's poorly designed as well. It might be something as simple as checking to ensure that expected elements are included in the response. The only valid example that I can think of where you may have blind inclusion (ie, you don't have a chance to verify what the results are before displaying) are frames (including iframes) and image links. I'm assuming we've all see those horrible websites that have a 'authentication required' message for every frame, but images are a little more subtle. The best thing to do for images is to serve an image back in response, rather than HTML. It's not a new thing; I remember doing it back when I worked for a university in the mid 1990s. We had your standard 'image-counter' CGI ... but when we realized that the majority of HTTP-referers were from outside the university, it was changed to instead return an image that said 'access denied' or something similar. -Joe
Re: [CODE4LIB] Crappy AJAX
On 10/25/12 7:37 AM, Joe Hourcle wrote: You didn't answer the question -- why would you not have some sort of check on the AJAX application (or any application, web or otherwise) to do at least minimal sanity checking on the result of an external call? Because putting the onus of sanity checking on the web page isn't the best solution in this case. Of course, it should be set up to handle unexpected results sensibly in any case. In the case of something requiring authentication, if it's a well designed back-end, it should return some HTTP status other than 200; 401 or 403 would be most appropriate. I've unfortunately worked with ColdFusion in the early days before they added cfheader to allow you to change the status code so that it was something other than 200. Which is exactly the point I was about to make before I read your second paragraph; the server, not the web page, should be fixed up to make things work sensibly. I've also seen websites that cheat to install a 'handler' for all requests by linking to a PHP script using Apache's 404 ErrorHandler directive. This also has the side effect that search engines won't index your site at all (as they assume it's all errors) In both of these cases, I'd say the service is poorly designed if you can't easily identify a failure. You can send a login page along with your 401 status, but you *should* *not* send a 30x redirect to a login page, as then the actual status message is lost. (the content hasn't been moved ... you just want someone to go to the login page ... the HTTP specs don't forbid a Location field w/ a 40x status, although I admit I've never verified that major browsers support it) I think we're in agreement here. -- Gary McGath, Professional Software Developer http://www.garymcgath.com
Re: [CODE4LIB] Crappy AJAX
On Oct 25, 2012, at 9:20 AM, Gary McGath wrote: On 10/25/12 7:37 AM, Joe Hourcle wrote: You didn't answer the question -- why would you not have some sort of check on the AJAX application (or any application, web or otherwise) to do at least minimal sanity checking on the result of an external call? Because putting the onus of sanity checking on the web page isn't the best solution in this case. Of course, it should be set up to handle unexpected results sensibly in any case. I view it like using JavaScript for form validation -- don't trust it, and still re-do the validation in the backend. If the costs to check tainted inputs are minimal, *do* *it*. Even when the back-end is well designed, there are enough other things out there that are outside your control. ... like when IE decided to start re-writing 404 and other status pages unless they happened to be at least 1k ... so even when we *were* giving informative messages about what was going on, links to report the problem, etc ... it never made it back to the user. (and yes, I know, I've officially hit old fogey status by complaining about changes that IE made more than 10 years ago ... I'm also not a fan of the br tag ... one of the worst mistakes of HTML+) But for more recent situations ... mobile browsers w/ spotty reception. Man-in-the-middle attacks ... deep-packet filtering (the firewall doesn't like some phrase used in the response, so replaces the content with a 'blocked' message ... they may not be common, but they *do* happen. -Joe
Re: [CODE4LIB] Crappy AJAX
On Oct 25, 2012, at 9:20 AM, Gary McGath develo...@mcgath.com wrote: Which is exactly the point I was about to make before I read your second paragraph; the server, not the web page, should be fixed up to make things work sensibly. http://www.google.com/search?q=Postel's+law -Ross.
Re: [CODE4LIB] Crappy AJAX
http://en.m.wikipedia.org/wiki/Sayre's_law On Oct 25, 2012 3:49 PM, Ross Singer rossfsin...@gmail.com wrote: On Oct 25, 2012, at 9:20 AM, Gary McGath develo...@mcgath.com wrote: Which is exactly the point I was about to make before I read your second paragraph; the server, not the web page, should be fixed up to make things work sensibly. http://www.google.com/search?q=Postel's+law -Ross.
Re: [CODE4LIB] Crappy AJAX
On Thu, Oct 25, 2012 at 6:51 AM, Chris Fitzpatrick chrisfitz...@gmail.comwrote: http://en.m.wikipedia.org/wiki/Sayre's_law ++Sayre's Law
Re: [CODE4LIB] Crappy AJAX
On Thu, 25 Oct 2012, Chris Fitzpatrick wrote: http://en.m.wikipedia.org/wiki/Sayre's_law I'm guessing the other people participating in this thread have never had men with guns show up to take your server because of a 'security incident'. Or block your server's IP address, and then make you jump through hoops for two weeks because they were unhappy with someone uploading an image to your trouble ticket system that accepted anonymous submissions ... with the explaination that if they managed to get a file on there, the whole system was compromised, and had to be blanked and the OS reinstalled. ... it didn't help that the image was text saying something to the effect of 'I've hacked your computer'. And they didn't realize at the time it actually had a JPEG exploit in it, so it was the people who downloaded it could've been compromised, but it wasn't even a valid exploit against the OS we were running. Or have all of the sysadmins in your group stop work for a day while we have a comprehensive scan of all of our machines by the security group because someone on the security auditing group noticed that a machine on our network sent out a request to some random webserver in the middle of the night, and then there was a connection attempted back to that machine and another one on our network. ... but they failed to mention was that the connection back was from a completely different IP range, and they had selectively filtered what they were looking for, so the incoming connections were attempted against *all* machines on our network and not a sign that someone was being selective in their attempts and cause for concern ... and the 'middle of the night' just meant 'before we got in this morning', but we have folks who have to work earlier shifts depending on when we get assigned antenna time to talk to the spacecraft. ... it makes the people who e-mail convinced that NASA's hiding evidence of the existance of alien life seem reasonable by comparison.* So I actually *do* have a stake in validating what we use as inputs. Other people might not, but I do my best to avoid a DOS from our security group.** -Joe * They don't like that we get highly compressed data for 'space weather' purposes, and we replace them with a higher-quality image once it's been downloaded through a higher bandwidth link. They also seem convinced that a compression artifact must be at the same distance from us as the sun for their size and speed calculations, rather than highly energetic particles right at the telescope. ** I've got other stories, too ... but I thought I'd keep it to only the ones that actually affected me.
