Twitch embed issues coming from v1.js

Hi, I work on with 2 other devs and we encountered an issue and we currently have no idea how to solve it anymore. We read multiple times the documentation, tried to modify the code in a lot of ways but the bug is still occurring.

This bug occurs straight after being connected to the website through Twitch Authentication, an iframe is generated using :
watch.nunj declares :

<script src=""></script>

Then TwitchViewer.vue declares :

    <div class="row">
        <div id="twitch-embed" class="embed-responsive embed-responsive-16by9 col-sm-12 col-lg-8"></div>
            class="col-sm-12 col-lg-4 p-0"

<script lang="ts">
const Twitch = window['Twitch'];

export default {
    name: 'TwitchViewer',

    props: {
        channel: String,

    data() {
        return {
            player: null,
            chat: null,

    computed: {
        chatUrl() {
            return `${}/chat?parent=${window.location.hostname}&darkpopout`;

    watch: {
        channel(val) {

    mounted() {

var embed = new Twitch.Player('twitch-embed', {
            layout: 'video',
            autoplay: true,
parent: ["", ""] 

        embed.addEventListener(Twitch.Embed.VIDEO_READY, () => {
            this.player = embed.getPlayer();

        embed.addEventListener(Twitch.Player.PLAYING, () => {

        embed.addEventListener(Twitch.Player.PAUSE, () => {

<style scoped>

But when a user connects, when the page loads immediately after that, the iframe that contains the current livestream will load the menu of Twitch or the “Developer” error (telling that the devs needs to put correct infos for it to work, I don’t have the exact translation) and in the Dev Tools console it will indicate a 404 error originating from this request made by v1.js :

EDIT : Forgot to mention this error originating from “twitch-passport” and “core-…” :

[ERROR] [auth] Login nonce mismatch. Error: Login nonce mismatch.


As you can all see, the oauth_token is undefined which is quite bizarre considering the player shouldn’t need it… ?

If anyone has a clue about what’s going on, I’d like to hear your thoughts and provided more code if needed.

We actually also checked if it was on our side (bad oauth token management or stuff like that) but after thinking about it for 2 days, there was nothing indicating there was a mistake or anything like that on our code (the code we made), and since you don’t need an oauth token for the player, it’s really suspicious.

Remove this and let the JS auto decide what to use.

I don’t see any broken embeds on the page linked to

Side note: your discord link is broken as it links to a channel, and I’m not in that server…

Upon login it works as expected.

Check the dev console for more information on the problem. And trace the issue back

Safe to ignore this is unrelated to embeds

Looks like a bug in twitch-passport assuming NodeJS you should be using

Which superseeds schmoopiie’s

1 Like

Thanks for your reply !

I wont be able to reply to all of this but :

  • parent is unnecessary but was added in case the bug was coming from here

  • you need to connect to Twitch from the portal from the webiste otherwise you wont encounter it. If you’re autoconnected it wont “work”.

  • As the oauth token is generated and used on the website and is not required to generate an iframe with v1.js

  • here’s a screenshot that will make it more processable for you, it’s from the development version. The bug is the same on the actual website.You can reproduce it by going on the website, go to the livestream page, clear all your cookies, click “StreamRunners”, then connect again.


You seem to have iframed the whole Twitch website here?!

I’m interested the error related to embeds, what is shown seems to be a pile of stuff relating to to an iFrame thats showing the whole Twitch website…

No, this is normally the iframe of the chat (${}/chat?parent=${window.location.hostname}&darkpopout), but it sometimes showing the home page of Twitch.

1 Like

Yes, to us (ionys and I are on the same team) it seems like both issues are linked and out of our control…

Rather than using two iFrames. Use embed everywhere to show one iFrame. Similar to this example:

If the chat is doing weird stuff like redirect to the home page that might be a thing to raise on the GitHub bug tracker.

1 Like

So I changed it so there is 1 iframe with both chat and video and removed the chat but…

…now the issue is that the chat is blocked but the player reloads correctly after 404.
I added the chat in the iframe back (as the video+chat has its chat blocked for some reason) and it’s just even more “unpredictable”. From times to times it triggers the bug even without having to authenticate. Sometimes the chat in the iframe loads when the bug is triggered : Meaning that now the chat is back, after testing for a bit it appears the video+chat has less chance to appear correctly and the chat from video+chat doesn’t load at all in any case…

I think your example is working because you don’t need to connect before. It looks like there is some kind of overlap between the authentication made by StreamRunners and the one by Twitch (from v1). I don’t quite understand how it’s possible but it looks like it’s what’s happening.

Shouldn’t be possible since Twitch doesn’t “see” the session running on StreamRunners. They are two totally different websites and neither will see each others authentication cookies or session.

I also cannot replicate the issue or have had reports of it not working from people using my properties that have Twitch auth (with video shown whether you are logged in or not)

I’ll continue investigating, but I really don’t know why the iframes are sending

incorrectly but when the page is reloaded the oauth_token query parameter is there, it’s only after connecting to Twitch from StreamRunners. Why isn’t the oauth token there ? Since it’s 404 from a Twitch script to a Twitch server, it means there might be an error on our end when requesting the iframe to be loaded but it seems unlikely as there would be an error in the logs mentioning it… :thinking:

I’m going to run a test where I’ll force the iframe to show my channel only and logging the channel that should’ve been requested if it wasn’t forced.

The test did nothing, still running into this error.

Also tested by manually making the iframe (with${}&layout=video-with-chat&migration=true&parent=${window.location.hostname}&referrer=http%3A%2F%2F127.0.0.1%3A3000%2F as the source of the iframe)

The bug still works with it…

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.