[links] rel and target attributes

[tmorehouse]

Adds target and rel attributes to all link-based components.

If target === '_blank' and rel is null then default rel to 'noopener'

Addresses #413

[tmorehouse]

Does the computedRel logic look OK to you @pi0 ?

[pi0]

Yep it seems nice :)

[alexsasharegan]

I think the this.target === '_blank' condition could be eliminated. It doesn't matter which target, you don't want to grant another domain context to your page, right? Or does it not matter because the window will be closed?

[pi0]

Sorry i was merged fast :)) So you mean adding noopener even to internal links?

[tmorehouse]

I didn't apply the rel/target to breadcrumb as typically breadcrumbs are in-domain (plus it would mean adding rel and target properties to each item in the list of items

[tmorehouse]

The only think I would be timid of, is if someone does want the opener property not set to noopener (which they can override by specifying an empty string for rel).

Just concerned that it could break some user use cases.

[alexsasharegan]

This would allow for any falsey value to drop the rel attribute, but it would probably break anyone depending on that communication as they will be forced to specify that prop now. But how many people use it that way?

props: {
        target: {
            type: String,
            default: null
        },
        rel: {
            type: String,
            default: 'noopener noreferrer'
        },
},
computed: {
    computedRel() {
        return this.target ? this.rel : null;
    }
}

[tmorehouse]

Maybe it should be up to the page author to specify any values, leaving security up to them?

[alexsasharegan]

So, I tested the window.opener prop on a link opened in the same window, and it is null. That makes sense because you just blew away the window by navigating to that link.

[alexsasharegan]

So maybe that means your computedRel is perfect the way it is?

[tmorehouse]

Note I defaulted target to _self as well in link mixin

[alexsasharegan]

As it is now, if I use the conventional _blank, I get the noopener. If I specify a rel prop, I get my rel. If I use a non-standard target, I have to specify the rel to get the security. All seems like reasonable to me.

[alexsasharegan]

Ship it! @pi0, you weren't premature on the merge after all.

[tmorehouse]

Should nofollow noreferrer also be added (for firefox)? Unless the newer firefox supports noopener?

[alexsasharegan]

Hmm... that's primarily an SEO concern, right? Now that we have a rel attribute, people have the ability to specify that at least.

[tmorehouse]

@alexsasharegan Oops, I meant noreferrer not nofollow

https://www.jitbit.com/alexblog/256-targetblank---the-most-underestimated-vulnerability-ever/

Update: FF does not support "noopener" so add this.

rel="noopener noreferrer"

[alexsasharegan]

I know that article makes it sound necessary, but when I look at the MDN page for an anchor tag, that attribute doesn't seem necessary. It just wipes your url from the referrer header on the request. Not sure how that is a security risk.

[tmorehouse]

True. So we'll leave it as is for now :)