Provided URLs are not validated

[Beanow]

While I do think URL validation should not be too strict, no validation may be a bit much freedom.
Using javascript:alert('hello world'); as URL works (which may result in issues when sharing with friends is enabled) as well as mistake which then points to http(s)://webistor.net/mistake.

Bigger usability problems happen with this example:
www.website.com which will point to http(s)://webistor.net/www.website.com

[bartwr]

A unique resource identifier can be omgilikecookies too, if that's what you want. Therefore I think there shouldn't be validation on the URI field.

[Beanow]

In that case, I think you shouldn't be able to click it as if it links to a web-page unless it is clearly an absolute URL (which would again break www.website.com because it has no http(s):// prefix).

[Avaq]

This field is called URI to mean Unique Resource Identifier. It's nothing more than a user-defined string of characters which identifies that particular resource: A unique-key. The World Wide Web adopted a similar way to identify resources and created URI: Uniform Resource Identifier. The latter has a strict specification attached to it, but Webistor should not enforce WWW URI's. However, since it will be the most common use for our URI field in Webistor, we can assume that we're generally providing some ease of access to our users by creating a link for them.

The problem lies with how these links are created. Right now we're just throwing it into an a[href] and letting the browser handle it. I think we should implement some kind of detection to "guess" the most appropriate action for our users. Much like how browsers decide whether to send you to a website or to your search-engine when entering a URI into the "omnibar".

• In case of a Uniform Resource Identifier (or something that could be cast to it reliably, like example.com): Send the user along to linked web-resource in a new tab.
• In case of a different Unique Resource Identifier: Open the Webistor resource in full-view mode.

The issue of sharing executable links with friends will be resolved by implementing Content Security Policy.

[Beanow]

Does the latter also protect against scripts that fit in the URI field without external resources? A memory flooding "practical joke" script for example. javascript:var a=[];while(1)a.push(Math.random())
We could opt to also not use a[href] for javascript: prefixed URI's.

[Avaq]

The way CSP is set up in my pull-request, in-line scripts are not loaded/executed. So yes, it would protect against such attacks.

[Beanow]

That's pretty sweet :] how does it tell actual scripts and scripts found in a json search result from the API apart? Based on the mime type? Or does it simply not include the API subdomain.

[Avaq]

The browser simply looks at the source of the script before executing it. If the source was not amongst the white-listed script-sources (defined by headers), it will not be executed. Script sources include generic URL's, but also keywords like in-line or eval. In-line is not in the white-list, so the browser will not execute anything directly from an a[href].

[Beanow]

Ahaa, so unless we would insert it into the DOM as a script element it will not execute without the in-line white-listing.

[bartwr]

{edited twice}

With the comments above I think we indeed need to fix the issue, "Provided URLs are not validated #17", by trying to recognize the URI the best way we can.

(But lets implement most of the other enhancements first.)

---

Oh, and first I mistood the concept

[...] since it will be the most common use for our URI field in Webistor, we can assume that we're generally providing some ease of access to our users by creating a link for them.

The problem lies with how these links are created. [...] I think we should implement some kind of detection to "guess" the most appropriate action for our users.

• In case of a different Unique Resource Identifier: Open the Webistor resource in full-view mode.

in @Avaq's post.

Avaq said: lets make non-recognized URI's clickable, so the Webistor resource clicked on opens in full-view mode. If you click recognized URI's though, send the user along to linked web-resource in a new tab..

I thought of this / I thought this would be nice too:

• In case of a Webistor resource URL like https://webistor.net/12348578: Open the linked Webistor resource in the active tab.

Referencing other Webistor resources is a good way to create links between different resources. We could change the anchor target for this type of URI's to "_self" instead of "_blank". This way chains develop.