Twitch Embedded Player Migration - Timeline Update

[jbulava]

As outlined in our previous announcement, the code used to deliver Twitch embeds will change in the near future. This post is another call to action for developers to review their current embed snippets and update them to use the latest required parameters (which are reiterated below). As of this writing, these changes will go into effect on June 10, 2020. Due to the nature of frame ancestor implementation and parent parameter requirements, this is a required change and your Twitch embeds will not function if they are not updated before this date.

You can read a quick reminder of what is changing below. For a more comprehensive explanation, please review the previous embed announcement mentioned above.

What’s changing?

The iframe and JavaScript code used to deliver Twitch embeds. More specifically, information regarding domain location and ancestors must be included in the iframe and JS code used to deliver Twitch embeds.

Note: Creating embed experiences from the Open Graph tags on a video page will be affected, though we’ve made considerable effort to make sure sharing Twitch links on popular social platforms will function as they currently do. If you are using our Open Graph tags to create embed experiences on your website, please review the changes and documentation to update your use accordingly.

Who will be affected by these changes?

Any third-party site or developer currently using embedded Twitch features (chat, video including Clips, and everything).

Why are we making these changes?

This implementation is a planned update to our embed architecture that utilizes the most recent enhancements and controls that the onsite Twitch player uses.

When do these changes take effect?

These changes will take effect on June 10, 2020. It should again be noted that embed experiences that have not been updated to utilize the latest parameters will no longer work after this date. If the parameters are present but not implemented correctly, viewers should see an error message with a link to our developer documents that should help with remediation steps.

Questions

If you have any questions or comments about this change, please let us know below.

[twitter_accounts]

Do you know if wildcard works? For instance lets say I have dynamically generating subdomains …

Can we use *.example.com to cover all of them?

---

Also another question that maybe sight off topic, will this update do anything to Twitch’s Dashboard Analytics in terms of “Where Views come from section”?

Right now there appears to be a issue with Analytics from embeds that are on certain domain and subdomains, example would be anything from *.blogspot.com that shows a Twitch Embed doesnt show up. Would this update to the embed player help get this to post up correctly on the analytics side of things?

---

You say you will cover popular social platforms, can you list what is approved?

Also - lets say right now my twitch live stream is doing something extremely unique, to which a 3rd part y gaming news website was to post a embed for … how would this work? Is it basically take the SHARE EMBED Code snip from the twitch page, copy it to their website and then they have to add their domain parent parameter?

[jbulava]

Hi! Hopefully the following points answer each of your questions in order:

• We will not support wildcards at this time.
• This update will not have any direct impact on the presentation or substance of Dashboard Analytics; there are also no plans at this time to augment the domains in that referrer information with subdomain-specific results.
• We can’t share the full list at this time, but you can safely assume that current sharing patterns to sites like Discord, Twitter, and Reddit should not be affected.
• The use case you mentioned will actually be addressed with an update to the “Share” snippet on channel pages that gives developers steps to implement the parent parameter effectively. Also, as a reminder, if a developer chooses to use the JavaScript embed file, that first parent parameter will be added automatically.

[twitter_accounts]

Just one more follow up - Will these changes and updates to the embedded player bring back Ads?

Right now no adverts show up on embeds or highlight vods posted on 3rd party websites and social media.

[jbulava]

The inclusion of ads is not part of this migration, however we will continue to explore revenue opportunities for our creators in future updates.

[bs1]

Hi.

Is it possible to verify that your website meets the new requirements before the changes take affect?
Maybe some kind of “strict mode” which can be used for testing where the parameter is required, or console warnings?

I think that would be helpful to prevent error messages when the changes are made.

[moonstar_x]

Hello there,

Regarding the frame-ancestors in the javascript embeds, whenever I try to access to my local server through localhost, everything works (despite the console errors that show up which I’m sure are safe to ignore). However, when trying to access the server through my machine’s local ip, instead of the embed I get the following JSON body:

{"errors":{"parent":["parent query string value contains invalid domain name"]},"title":"One or more validation errors occurred.","status":400}

What should I do in this case?

---

Regarding the SSL certification requirement, if I try to embed any of the players on a local server that only runs on HTTP rather than HTTPS, should I expect to work or will there be issues? The question applies when accessing the server through localhost and the machine’s local IP.

Thanks in advance!

[jbulava]

Yes. At this time, we are currently sending Content-Security-Policy-Report-Only response headers for the player.twitch.tv requests when the parent and migration parameter are provided. migration should be set to true.

Here is an example:

<iframe
    src="https://player.twitch.tv/?channel=monstercat&migration=true&parent=MYDOMAIN"
    height="720" width="1280" frameborder="0" scrolling="no" allowfullscreen="false">
</iframe>

If you go into the network traffic of your browser and look at the request to player.twitch.tv, you should see the Content-Security-Policy-Report-Only header. If the everything is fine, you will not see anything in the browser console. If there is a potential error with the embed, you will see the following message in the developer console (note the embed will still occurr as this is just a report).

[Report Only] Refused to frame 'https://player.twitch.tv/' because an ancestor violates the following Content Security Policy directive: "frame-ancestors https://MYDOMAIN".

Sometime before June 10, we may always return the report header. As of June 10, we will always return CSP header.

[mikegreen]

Hi twitch dev,

There seems to be an issue with the domain name validation.

We require the parent to be an ip address for development testing e.g. parent=192.1.1.1

When an ip address is used, the error we receive is “parent query string value contains invalid domain name”. moonstar_x reported the same issue above.

Test url:
https://player.twitch.tv/?channel=insomniac&migration=true&parent=192.1.1.1&referrer=https%3A%2F%2F192.1.1.1%3A

Thanks,
Mike

[kaldune02]

I’m a bit confused as to how Chrome handles the Content-Security-Policy-Report-Only header. In a staging environment using a cert issued by a CA, no console message is logged. But in local environments with a self-signed certificate, Chrome spits out a [Report Only] error. This doesn’t give much confidence that things won’t break for local development after June 10.

Here’s some findings using the player iframe embed.

&migration=true&parent=localhost
Content-Security-Policy-Report-Only: frame-ancestors localhost
[Report Only] Refused to frame ‘https://player.twitch.tv/’ because an ancestor violates the following Content Security Policy directive: “frame-ancestors localhost”.

&migration=true&parent=localhost:8000
400 Bad Request

&migration=true&parent=https://localhost
400 Bad Request

&migration=true&parent=https://localhost:8000
400 Bad Request

This also doesn’t work (localdev.com mapped to 127.0.0.1):

&migration=true&parent=localdev.com
Content-Security-Policy-Report-Only: frame-ancestors https://localdev.com
[Report Only] Refused to frame ‘https://player.twitch.tv/’ because an ancestor violates the following Content Security Policy directive: “frame-ancestors https://localdev.com”.

[kaldune02]

I’ve spent over 4 hours trying to get local development working with no luck. Tried hosting locally on port 80 and 8000. Tried different combinations of scheme, hostname, port for the parent. Either a 400 Bad Request is returned from player.twitch.tv or Chrome just doesn’t like localhost specified in frame-ancestors.

Not sure what to do at this point. I don’t want to disable CSP in the browser. There’s gotta be an easier way. You can repro this easily by using a starter Next.js, Gatsby.js, or Create React App and embed the twitch player.

[bs1]

Thanks for your reply.

As other users mention, I’m also having “invalid domain name” issue when domain is an ip address, which is a problem in development environment.

Hope this can be fixed.

[jbulava]

@moonstar_x @mikegreen @kaldune02 @bs1

The team has provided additional information regarding local development and a change to go along with the June 10 update to fix the situation described below.

localhost and anything in the 127.0.0.0/8 IP range is an acceptable value for parent (e.g. parent=localhost or parent=127.0.0.1). As it stands at the moment though, since the player is served over HTTPS, so does your local development for successful CSP URL matching according to the spec (added the link for reference only if you’re curious). In other words, if you specify parent=localhost, your local development needs to be served on https://localhost:443 or if you specify parent=127.0.0.1, your local development needs to be served on https://127.0.0.1:443. Note that the CSP does not require the HTTPS connection to actually have a valid certificate.

All of that said and recognizing that this is not ideal for local development, the team is going to implement a change next week that makes an exception for local development. With that change, localhost and the 127.0.0.0/8 IP range will be able to accept HTTP and any port (though the port should not be specified in the parent value as ports are not valid in the expression). In other words, with that change, you will not need to have HTTPS set up for local development.

Hopefully this helps explain the current situation and how it’ll be addressed next week.

[mikegreen]

Thanks @jbulava

If you have to restrict the ip range then we’d like to request the 192.168.x.y range to be included, which references servers on the local network.

When we do testing for mobile devices, we aren’t able to access 127.0.0 range because the development server is running on another computer (and not on the phone itself).

[jbulava]

I’ll pass along this request. Out of curiosity, would you be willing to share a link to your app here or in a DM? It would be great to pass along your use case with a working example.

[mikegreen]

This is only an issue during development and testing which aren’t public links.

Here’s the link that the Twitch JS API generates automatically:
https://player.twitch.tv/?channel=insomniac&migration=true&parent=192.168.1.1&referrer=https%3A%2F%2F192.168.1.1%3A

Thanks!

[jbulava]

Thanks for sharing the testing link. Though I was looking for your App Store link if it’s in production (i.e. https://itunes.apple.com/en/app/XXXX). I’d like some examples of mobile apps using Twitch Embeds to share as it is a lesser known use case.

[mikegreen]

Oo we are embedding in a website like a normal use case. However, we do a lot of testing using the browsers on mobile devices since iOS and Android have different ways of working and usability concerns e.g. one platform might only allow autoplay if muted

[jbulava]

Ah, got it! That makes sense.

[Si_toxx]

Hey. How to hide topBar? Will the new version of Player Twitch have adaptability? Or will it still work crookedly? If it is not possible to find out all levels of nesting, will the player work?