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.
>>> 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
>etc. I think there's no end to the creative ways that developers and
>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
I will not discuss this further on-list.
Gary McGath, Professional Software Developer http://www.garymcgath.com