Re: Solving the "Deep Linking" (bookmarkability) problem in RWW for single page applications

On 27 December 2013 22:15, Sébastien Lorber <sebastien@stample.co> wrote:

> Hi all,
>

Hi & welcome to the group! :)


>
> I'm working with Henry and I'm trying to build a Single Page Application
> (SPA) that can navigate to the RWW.
> I can't find an elegant way to handle deep linking (possibility to
> bookmark/share the url) without reloading the whole page, which is not
> really a modern user experience.
>
>
>
> Suppose I have an RDF resource located at http://sub.rwwserver.io/resource
>
> The server actually detects that it's a browser with Accept prefering html
> content, so it sends some generic html page with some JS in it that will
> refetch the resource in RDF format, and startup the SinglePageApp to render
> that RDF graph.
>
> This is a SinglePageApp so we aim to not refresh the page and reload the
> app as we navigate through the RDF graphs.
>
>
> If this resource is a foaf profile:
> http://sub.rwwserver.io/profile
> Then on my SPA can eventually click on a friend of this foaf profile
> (foaf:knows) which will lead to a rendering the friend data, on which you
> can also click on one of its friends...
>
> When rendering a friend, as we are in a SPA, the url remain
> http://sub.rwwserver.io/profile
> So if I want to bookmark or share the friend's page, I can't simply use
> the browser current url.
>
>
> If the rendered friend is part of the subdomain, with HTML5 history
> pushState (or History.js) it is possible to modify the url and add an
> history element.
>
> So if the first user to render is
> http://sub.rwwserver.io/profile1
> And then we render its friend
> http://sub.rwwserver.io/profile2
> it is possible to change the current url to profile2 url without reloading
> the page, even if the loaded page was profile1 url
>
> But it's not possible to change the url without reloading if the url to
> set is on another domain or subdomain. This is a security issue because if
> you go to hacker.com, the site could change the url to yourbank.com and
> do some fishing more easily.
>
>
>
>
>
>
> So what is the solution to build modern JS RDF applications (SPA) and be
> able to solve this deep linking problem?
>
>
> We could probably change the url when the domain is the same, and redirect
> to the new resource to render when the domain is different. That wouldn't
> always redirect in many cases, particularly when the user navigate in its
> own content for exemple.
> But when dealing with stuff like navigating in social networks and foaf
> profiles, it is very probable that the domain will often change between
> users...
>
>
>
>
>
>
>
> Js frameworks like Angular and Backbone usually use the url hash to
> perform routing and solve this deep linking problem.
>
> So I may be able to use something like that:
>
> http://sub.rwwserver.io/profile#currentResource=http://otherrww.io/otherprofile
> This way the url becomes bookmarkable and shareable, but the problem is
> it's not really the true resource url that you share, and that many urls of
> this kind (with hash) could point to the same resource url:
>
> http://sub.rwwserver.io/someContent#currentResource=http://otherrww.io/otherprofile
>
> http://test.rwwserver.io/#currentResource=http://otherrww.io/otherprofileThiskind of defeat the original goal of an url I guess.
>
> And if the first url is not available anymore, the link won't work, even
> if the targeted resource is still available...
>
>
>
> In addition, in my opinion, an user should be able to "choose" the
> application he wants to open an RDF resource, as we can currently do in OS:
> you can open .doc files with Word or OpenOffice, and have a default
> prefered app. So many SPA could be used to render the same foaf profile.
>
> If I choose app1 to render a profile, app1 may create a
> #currentResource=url . and then I can send the link to someone.
> But this other person may prefer to renderprofiles with app2, and maybe
> app2 is not able to understand the hash semantics used by app1 for deep
> linking, so it will render the original profile and not the profile in
> #currentResource=url
>
> This could eventually become a hacky standard for building RWW SPA, to use
> the same hash semantics.
> But another problem is ACL. If I share a link
> originalResource#currentResource=url
> then i have myself access to originalResource, but the other user may not
> have access so the server won't load any SPA even if that other user have
> access to the targeted resource
>
> It could perhaps be done at the RWW server level (not sure, the url hash
> is sent?) so that the server automatically redirect the client to the
> targeted resource (without checking ACLs on the original) if it detects the
> #currentResource=url fragment
> But this doesn't solve:
> - the RWW server could be down
> - the url is ugly
>
>
>
>
>
>
>
> Do you see any solution to this problem?
>
>
> One solution could be to have some kind of equivalent of:
> Access-Control-Allow-Origin: *
> lke
> Access-Control-Allow-History-PushState: *
> implemented on browsers and added on RWW server responses, but it wouldn't
> really prevent fishing because hacker.com could change the url to
> http://rwwserver.io/myBankAccount and show credit card forms...
> Maybe this can be used only on non-sensitive RDF resource url
>
> What do you think?
>

Very interesting use case, thanks for raising it.  We have the same issue
in tabulator.

I wonder if the ideal solution would be something like when the browser
asks you for your location.

There could be a popup saying:

"This site wishes to change the value in your address bar"

- Allow once
- Always allow

The issue might be then that the value in the address bar may not match the
actual content, so perhaps a little signal could appear next to the address
to show that it is not definitive.

Do you think that would work?

PS Regarding using the # character, whatever is after the hash should never
been seen by the server, but you can use a ? like in:

http://graphite.ecs.soton.ac.uk/browser/?uri=http%3A%2F%2Fmelvincarvalho.com%2F




> Thanks
>
>
>
>