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 <[log in to unmask]> wrote:
>>> On 10/24/12 4:00 PM, Ross Singer wrote:
>>>> On Oct 24, 2012, at 3:48 PM, Gary McGath <[log in to unmask]> 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