 |
 |
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: >> >>> With AJAX, a resource can be brought up by refreshing part of an >>> existing page rather than as a whole new page. If the page is expecting, >>> for example, a JPEG image, and the request for the image is redirected >>> to a login page because it's restricted, then the page won't get back an >>> image, but instead will get back the HTML for the login page. The HTML >>> <img> tag can't do anything with this, and it will merely fail to >>> display the image. >>> >> >> What does this have to do with discovery interfaces? > > The issue is generic to any web application that has a mix of public and > restricted resources and may encounter restricted ones at unexpected > times, such as was being discussed with discovery interfaces. > The discovery interface knows what is restricted. That's why it's saying you don't have access to them until you log in. >> 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. > I'm not sure this is the appropriate venue for getting into the > technical details, and I've encountered the problem without having > managed to implement a solution, but I'll briefly cover how I'd attack > the problem. > > If the resource redirects to an HTML login page, the Ajax code can't > make any sense of that, so it can't be "prepared for such an event." Sure it can. I mean, no matter what, you're constrained by same origin policy, so any 'login' is going to be something local, so it seems pretty easy to account for. Bringing JSONP and CORS into the mix doesn't really change anything, as I can't imagine you're just blindly pulling in content from some external site. > However, if the response has an HTTP code indicating that authentication > is required, the Ajax error handler can dispatch on the code and > dispatch an event which is handled at the page's top level, forcing the > whole page to redirect to the login. This is doable but a bit messy and > reduces the value of AJAX. Giving an indication that not all resources > could be loaded and providing the option to log in is cleaner. AJAX isn't some magical potion that eliminates the need to plan and engineer your app. I don't think 'accounting for the web being a messy place' reduces the value of AJAX. It means you have to earn your keep. You know, as a professional software developer. >> >> There are lots of things everywhere (not just library-related) that require logins. The internet hasn't broken as a result. > > I'm afraid I don't understand how this relates to what I was discussing. Which goes back to how I don't understand what AJAX has to do with the fact that some things aren't, by default, being displayed in discovery interfaces. > I didn't deny either of those points (though the Internet is always in a > partly broken state). By "require login," do you mean "automatically > redirect a request for a restricted resource to a login page"? I find > that's more the exception than the rule. > Depends. There's tons of content that requires a login to see: stuff in VLEs; Facebook statuses; corporate intranets; Pinboard bookmarks; subscriber paywalls; etc. I think there's no end to the creative ways that developers and designers block public access to things. -Ross. > > > -- > Gary McGath, Professional Software Developer http://www.garymcgath.com