views:

40

answers:

2

I have an application that utilizes rather unfriendly dynamic URLs most of the time. I am providing friendly URLs to some content, but these are used only as an entry point into the application, after which point all of the generated URLs will be the unfriendly variety.

My question is, if I know that the user is on a page for which a friendly URL could be generated and they choose to bookmark it, is there a way to tell the browser to bookmark the friendly one instead of what is in the address bar?

+1  A: 

I had hoped that rel="canonical" would help here, but it seems as if it's only used for indexing. Maybe one day browsers will utilise it.

Alan
+1 because while this doesn't solve the question, I need exactly this functionality anyhow for search engine indexing.
bgould
+1  A: 

No. This is by design, and a Good Thing.

Imagine the following scenario: Piskvor surfs to http://innocentlookingpage.example.com/ and clicks "bookmark". He doesn't notice that the bookmark he saved points to http://evilsite.example.net/ Next time he opens that bookmark, he might get a bit of a surprise.

Another example without cross-domain issues: Piskvor the site admin clicks "bookmark" on the homepage of http://security-holes-r-us.example.org/ - unfortunately, the page is vulnerable to script injection, and the injected code changes the bookmark to http://security-holes-r-us.example.org/admin?action=delete&what=everything&sure=absolutely . If he's still logged in the next time he opens the bookmark, he may find his site purged of data (Granted, it was his fault not to prevent script injection AND to have non-idempotent GET resources, but that is all too common).

Piskvor
I agree with the scenario that you describe, but I'm not trying to cross domains here, so I don't think that this is any more dangerous that domain-scoped cookies or SOP on xmlhttprequest.
bgould
@bgould: Indeed. I know that you mean no harm, and you know it; but trust is one of the hardest things to put into code, the Right Way and without security holes. It's much easier (and subsequently safer) to code "this is not allowed, ever" than "this is not allowed, except when X, and also Y, but not when Y and Z, and during a full moon".
Piskvor