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

Hi,

most of the mobile platforms actually don't present the current URL to
the user at all (e.g. if you install an open web app [1] with Firefox
for Android or on Firefox OS), because the SPA is treated equally as an
native app without browser UI. Firefox nightly also supports to install
these apps as kind of "native" apps on Windows, Linux distributions and
OSX, running in a stripped down Firefox window without UI with
integration into the program launchers of the system (e.g. GNOME dashboard).

If one follows that path it would be okay to just ignore the URL
altogether and present the "current" URL that may be bookmarkeable
inside the SPA with its own UI.

[1]
https://developer.mozilla.org/en-US/Apps/Quickstart/Build/Intro_to_open_web_apps

Regards,
Niclas

Am 27.12.2013 22:15, schrieb Sébastien Lorber:
> Hi all,
>
> 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 <http://hacker.com>, the site could
> change the url to yourbank.com <http://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/otherprofileThis
> kind 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 <http://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?
>
> Thanks
>
>
>