Link Support: target and rel attributes

[alexsasharegan]

When working with some of the special components that take to or href attributes (basically components using the link mixin), there isn't support for passing down the target and rel attributes.

I would love it if the default prop value for rel was rel="noopener noreferrer" to add a security-boosting default per this article: https://www.jitbit.com/alexblog/256-targetblank---the-most-underestimated-vulnerability-ever/. Maybe that could be triggered with a computed property so it only kicks in if a target other than _self is specified.

<template>
    <b-navbar toggleable
              type="inverse"
              variant="primary">
        <b-nav is-nav-bar>
            <b-nav-item :href="FACEBOOK"
                        target="_blank"
                        rel="noopener noreferrer">
                <i class="fa fa-fw fa-facebook"></i>
            </b-nav-item>
        </b-nav>
    </b-navbar>
</template>

[tmorehouse]

Rather than putting too much logic into the component, we could just provide new props (target and rel) to the link component(s), and rely on the user assigning values appropriately for their use case.

[alexsasharegan]

Definitely! Slim and trim!

[tmorehouse]

I'll work on a PR for adding the two new props.

[alexsasharegan]

Gracias, señor!

[pi0]

I agree with troy. But only about rel=noopener it is REQUIRED for PWA checklist when target=_blank so what's your idea using a computed prop for rel and adding this automatically when no rel provided?

[tmorehouse]

Hmmm... so create a computed prop computedRel that is based on both this.rel and this.target (depending on their values or lack of values)?

[tmorehouse]

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

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

rel="noopener noreferrer"

So should it default to both if target="_blank"?

What about cases where a user is linking to their own website (i.e. same domain) and wants _blank, but also needs the referer set?

Maybe if this.rel is null then default the rel for target _blank, but if this.rel is set to an empty string then remove the rel attribute?

[tmorehouse]

I can see defaulting rel for user supplied link content, but if it is author supplied content, then it shouldn't be set (maybe)?

[alexsasharegan]

Not to complicate things, but you can put any string in target that isn't _self (I believe), and you alias a new window.

[alexsasharegan]

I would say the rel has a default value of noopener noreferrer, but only kicks in when the target attribute is null or not _self. Then if the user overrides it, they can set it to null. So that has computed prop written all over it to me.

[tmorehouse]

@alexsasharegan true, any target that is not preceded by an _ opens a new (referenceable) window.

[tmorehouse]

take a look at PR #418 and see what you think

[alexsasharegan]

So, I was getting myself confused about opening in a new window or in the same window. Really, you would only want to add the rel attribute if the link is not same domain. That's hard to do without adding too much code.

Took a look at you addition. Looks good, but I think the noopener should be on any non-null target. Thoughts?

[tmorehouse]

But what if the user does want window to window communication for their own domain?

[alexsasharegan]

That's why I think it might be more advantageous to default to noopener. Then check that target is not null, and just return the rel. Then they can specify null if they need communication.

[tmorehouse]

What about if target is not _self or _top, then don't set noopener?

[alexsasharegan]

Maybe we should try to keep this on the PR. I'm getting dizzy!

[tmorehouse]

PR #418 Merged