 |
 |
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: >>> >>>> 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. Agreed. >>> 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. > >> 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. It's a matter of the difference between, for example, the src attribute of an <img> tag and a web page. Again, I don't want to turn this into a full-fledged programming discussion on-list. > > 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. I've been trying to respond to you seriously, but at this point you're really starting to sound like a troll. Addressing a technical issue by saying "you have to earn your keep" is no answer at all, particularly when you aren't paying me. >>> 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. Then why are you so insistent on auto-redirect as the only way to do it? I can't check every one of the things you mention, but Facebook statuses in particular do _not_ auto-redirect to a login page. Perhaps you really don't understand the difference between auto-redirecting a resource to a login page and having a login link or button on a page indicating content is unavailable. In that case, I have to recommend you get better informed on basic concepts of access restriction. I will not discuss this further on-list. -- Gary McGath, Professional Software Developer http://www.garymcgath.com