Persistent error.api.youtube.login despite correct session-generator setup #775

Closed
opened 2025-11-09 09:58:08 -06:00 by GiteaMirror · 18 comments
Owner

Originally created by @otakukz17 on GitHub (Mar 23, 2025).

problem description

After correctly configuring the yt-session-generator, the API continues to return a YouTube authentication error for all video requests.
In the Docker logs:

cobalt API ^ω^


version: 10.8.2

commit: 0a7cf7580cdedd8494686f19641fb24fc3e80326

branch: main

remote: imputnet/cobalt

start time: Sun, 23 Mar 2025 16:00:30 GMT

url: http://129.151.212.247:9000

port: 9000

[✓] poToken & visitor_data loaded successfully!

[✓] api keys loaded successfully!

your instance configuration

services:
  cobalt-api:
    image: ghcr.io/imputnet/cobalt:10
    init: true
    read_only: true
    restart: unless-stopped
    container_name: cobalt-api
    networks:
      - cobalt-net
    ports:
      - 9000:9000/tcp
      # if you use a reverse proxy (such as nginx),
      # uncomment the next line and remove the one above (9000:9000/tcp):
      # - 127.0.0.1:9000:9000
    environment:
      # replace https://api.url.example/ with your instance's url
      # or else tunneling functionality won't work properly
      API_URL: "http://129.151.212.247:9000"
      API_KEY_URL: "file:///app/keys.json"
      API_AUTH_REQUIRED: "1"
      YOUTUBE_SESSION_SERVER: "http://localhost:8080/token"
      # if you want to use cookies for fetching data from services,
      # uncomment the next line & volumes section
      # COOKIE_PATH: "/cookies.json"
      
      # it's recommended to configure bot protection or api keys if the instance is public,
      # see /docs/protect-an-instance.md for more info
      
      # see /docs/run-an-instance.md for more variables that you can use here
    labels:
      - com.centurylinklabs.watchtower.scope=cobalt
    # uncomment only if you use the COOKIE_PATH variable
    volumes:
      - ./keys.json:/app/keys.json:ro
      # - ./cookies.json:/cookies.json
    depends_on:
      yt-session-generator:
        condition: service_healthy

  # watchtower updates the cobalt image automatically
  watchtower:
    image: ghcr.io/containrrr/watchtower
    restart: unless-stopped
    command: --cleanup --scope cobalt --interval 900 --include-restarting
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock

  # if needed, use this image for automatically generating poToken & visitor_data
  yt-session-generator:
    image: ghcr.io/imputnet/yt-session-generator:webserver
    init: true
    networks:
      - cobalt-net
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8080/token"]
    restart: unless-stopped
    container_name: yt-session-generator
    ports:
      - 127.0.0.1:1280:8080

networks:
  cobalt-net:
    driver: bridge
Originally created by @otakukz17 on GitHub (Mar 23, 2025). ### problem description After correctly configuring the `yt-session-generator`, the API continues to return a YouTube authentication error for all video requests. In the Docker logs: cobalt API ^ω^ ~~~~~~ version: 10.8.2 commit: 0a7cf7580cdedd8494686f19641fb24fc3e80326 branch: main remote: imputnet/cobalt start time: Sun, 23 Mar 2025 16:00:30 GMT ~~~~~~ url: http://129.151.212.247:9000 port: 9000 [✓] poToken & visitor_data loaded successfully! [✓] api keys loaded successfully! ### your instance configuration ```shell services: cobalt-api: image: ghcr.io/imputnet/cobalt:10 init: true read_only: true restart: unless-stopped container_name: cobalt-api networks: - cobalt-net ports: - 9000:9000/tcp # if you use a reverse proxy (such as nginx), # uncomment the next line and remove the one above (9000:9000/tcp): # - 127.0.0.1:9000:9000 environment: # replace https://api.url.example/ with your instance's url # or else tunneling functionality won't work properly API_URL: "http://129.151.212.247:9000" API_KEY_URL: "file:///app/keys.json" API_AUTH_REQUIRED: "1" YOUTUBE_SESSION_SERVER: "http://localhost:8080/token" # if you want to use cookies for fetching data from services, # uncomment the next line & volumes section # COOKIE_PATH: "/cookies.json" # it's recommended to configure bot protection or api keys if the instance is public, # see /docs/protect-an-instance.md for more info # see /docs/run-an-instance.md for more variables that you can use here labels: - com.centurylinklabs.watchtower.scope=cobalt # uncomment only if you use the COOKIE_PATH variable volumes: - ./keys.json:/app/keys.json:ro # - ./cookies.json:/cookies.json depends_on: yt-session-generator: condition: service_healthy # watchtower updates the cobalt image automatically watchtower: image: ghcr.io/containrrr/watchtower restart: unless-stopped command: --cleanup --scope cobalt --interval 900 --include-restarting volumes: - /var/run/docker.sock:/var/run/docker.sock # if needed, use this image for automatically generating poToken & visitor_data yt-session-generator: image: ghcr.io/imputnet/yt-session-generator:webserver init: true networks: - cobalt-net healthcheck: test: ["CMD", "curl", "-f", "http://localhost:8080/token"] restart: unless-stopped container_name: yt-session-generator ports: - 127.0.0.1:1280:8080 networks: cobalt-net: driver: bridge ```
GiteaMirror added the instance hosting help label 2025-11-09 09:58:08 -06:00
Author
Owner

@ccf-zeno commented on GitHub (Mar 24, 2025):

一样的问题,求助

@ccf-zeno commented on GitHub (Mar 24, 2025): 一样的问题,求助
Author
Owner

@ubranch commented on GitHub (Mar 26, 2025):

same problem

@ubranch commented on GitHub (Mar 26, 2025): same problem
Author
Owner

@2shiraz commented on GitHub (Mar 26, 2025):

problem is with the ip of wherever you are hosting.

@2shiraz commented on GitHub (Mar 26, 2025): problem is with the ip of wherever you are hosting.
Author
Owner

@danilt2000 commented on GitHub (Apr 7, 2025):

i have the same problem please help

@danilt2000 commented on GitHub (Apr 7, 2025): i have the same problem please help
Author
Owner

@elkofy commented on GitHub (Apr 11, 2025):

I have the same problem too I can't figure out why since it works on my machine without youtube session generator.

@elkofy commented on GitHub (Apr 11, 2025): I have the same problem too I can't figure out why since it works on my machine without youtube session generator.
Author
Owner

@FethiAmari commented on GitHub (Apr 16, 2025):

problem description

After correctly configuring the yt-session-generator, the API continues to return a YouTube authentication error for all video requests. In the Docker logs:

cobalt API ^ω^


version: 10.8.2

commit: 0a7cf7580cdedd8494686f19641fb24fc3e80326

branch: main

remote: imputnet/cobalt

start time: Sun, 23 Mar 2025 16:00:30 GMT

url: http://129.151.212.247:9000

port: 9000

[✓] poToken & visitor_data loaded successfully!

[✓] api keys loaded successfully!

your instance configuration

services:
cobalt-api:
image: ghcr.io/imputnet/cobalt:10
init: true
read_only: true
restart: unless-stopped
container_name: cobalt-api
networks:
- cobalt-net
ports:
- 9000:9000/tcp
# if you use a reverse proxy (such as nginx),
# uncomment the next line and remove the one above (9000:9000/tcp):
# - 127.0.0.1:9000:9000
environment:
# replace https://api.url.example/ with your instance's url
# or else tunneling functionality won't work properly
API_URL: "http://129.151.212.247:9000"
API_KEY_URL: "file:///app/keys.json"
API_AUTH_REQUIRED: "1"
YOUTUBE_SESSION_SERVER: "http://localhost:8080/token"
# if you want to use cookies for fetching data from services,
# uncomment the next line & volumes section
# COOKIE_PATH: "/cookies.json"

  # it's recommended to configure bot protection or api keys if the instance is public,
  # see /docs/protect-an-instance.md for more info
  
  # see /docs/run-an-instance.md for more variables that you can use here
labels:
  - com.centurylinklabs.watchtower.scope=cobalt
# uncomment only if you use the COOKIE_PATH variable
volumes:
  - ./keys.json:/app/keys.json:ro
  # - ./cookies.json:/cookies.json
depends_on:
  yt-session-generator:
    condition: service_healthy

watchtower updates the cobalt image automatically

watchtower:
image: ghcr.io/containrrr/watchtower
restart: unless-stopped
command: --cleanup --scope cobalt --interval 900 --include-restarting
volumes:
- /var/run/docker.sock:/var/run/docker.sock

if needed, use this image for automatically generating poToken & visitor_data

yt-session-generator:
image: ghcr.io/imputnet/yt-session-generator:webserver
init: true
networks:
- cobalt-net
healthcheck:
test: ["CMD", "curl", "-f", "http://localhost:8080/token"]
restart: unless-stopped
container_name: yt-session-generator
ports:
- 127.0.0.1:1280:8080

networks:
cobalt-net:
driver: bridge

Hello bro can you help me how can i contact you

@FethiAmari commented on GitHub (Apr 16, 2025): > ### problem description > After correctly configuring the `yt-session-generator`, the API continues to return a YouTube authentication error for all video requests. In the Docker logs: > > cobalt API ^ω^ > > ``` > > version: 10.8.2 > > commit: 0a7cf7580cdedd8494686f19641fb24fc3e80326 > > branch: main > > remote: imputnet/cobalt > > start time: Sun, 23 Mar 2025 16:00:30 GMT > ``` > > url: http://129.151.212.247:9000 > > port: 9000 > > [✓] poToken & visitor_data loaded successfully! > > [✓] api keys loaded successfully! > > ### your instance configuration > services: > cobalt-api: > image: ghcr.io/imputnet/cobalt:10 > init: true > read_only: true > restart: unless-stopped > container_name: cobalt-api > networks: > - cobalt-net > ports: > - 9000:9000/tcp > # if you use a reverse proxy (such as nginx), > # uncomment the next line and remove the one above (9000:9000/tcp): > # - 127.0.0.1:9000:9000 > environment: > # replace https://api.url.example/ with your instance's url > # or else tunneling functionality won't work properly > API_URL: "http://129.151.212.247:9000" > API_KEY_URL: "file:///app/keys.json" > API_AUTH_REQUIRED: "1" > YOUTUBE_SESSION_SERVER: "http://localhost:8080/token" > # if you want to use cookies for fetching data from services, > # uncomment the next line & volumes section > # COOKIE_PATH: "/cookies.json" > > # it's recommended to configure bot protection or api keys if the instance is public, > # see /docs/protect-an-instance.md for more info > > # see /docs/run-an-instance.md for more variables that you can use here > labels: > - com.centurylinklabs.watchtower.scope=cobalt > # uncomment only if you use the COOKIE_PATH variable > volumes: > - ./keys.json:/app/keys.json:ro > # - ./cookies.json:/cookies.json > depends_on: > yt-session-generator: > condition: service_healthy > > # watchtower updates the cobalt image automatically > watchtower: > image: ghcr.io/containrrr/watchtower > restart: unless-stopped > command: --cleanup --scope cobalt --interval 900 --include-restarting > volumes: > - /var/run/docker.sock:/var/run/docker.sock > > # if needed, use this image for automatically generating poToken & visitor_data > yt-session-generator: > image: ghcr.io/imputnet/yt-session-generator:webserver > init: true > networks: > - cobalt-net > healthcheck: > test: ["CMD", "curl", "-f", "http://localhost:8080/token"] > restart: unless-stopped > container_name: yt-session-generator > ports: > - 127.0.0.1:1280:8080 > > networks: > cobalt-net: > driver: bridge Hello bro can you help me how can i contact you
Author
Owner

@yonnic commented on GitHub (Apr 22, 2025):

guys the problem is with your datacenter IPs getting blocked because they are not what every day people use at home.
You need a residential IP proxy to make this work

@yonnic commented on GitHub (Apr 22, 2025): guys the problem is with your datacenter IPs getting blocked because they are not what every day people use at home. You need a residential IP proxy to make this work
Author
Owner

@ubranch commented on GitHub (Apr 22, 2025):

guys the problem is with your datacenter IPs getting blocked because they are not what every day people use at home. You need a residential IP proxy to make this work

so the content also will be downloaded through that proxy server, right ? i'm about traffic usage through proxy

@ubranch commented on GitHub (Apr 22, 2025): > guys the problem is with your datacenter IPs getting blocked because they are not what every day people use at home. You need a residential IP proxy to make this work so the content also will be downloaded through that proxy server, right ? i'm about traffic usage through proxy
Author
Owner

@yonnic commented on GitHub (Apr 22, 2025):

guys the problem is with your datacenter IPs getting blocked because they are not what every day people use at home. You need a residential IP proxy to make this work

so the content also will be downloaded through that proxy server, right ? i'm about traffic usage through proxy

yes sadly thats a big downside as residential IP bandwidth is very expensive. I pay like 8$ / gb.
I use the service from oxylabs.io - it must be residential and support HTTP. Other types like HTTPS or SOCKS5 are not supported.

As an alternative you can set up a home proxy on some raspberry pi but the downside is that your IP will not change often

@yonnic commented on GitHub (Apr 22, 2025): > > guys the problem is with your datacenter IPs getting blocked because they are not what every day people use at home. You need a residential IP proxy to make this work > > so the content also will be downloaded through that proxy server, right ? i'm about traffic usage through proxy yes sadly thats a big downside as residential IP bandwidth is very expensive. I pay like 8$ / gb. I use the service from oxylabs.io - it must be residential and support HTTP. Other types like HTTPS or SOCKS5 are not supported. As an alternative you can set up a home proxy on some raspberry pi but the downside is that your IP will not change often
Author
Owner

@ubranch commented on GitHub (Apr 22, 2025):

guys the problem is with your datacenter IPs getting blocked because they are not what every day people use at home. You need a residential IP proxy to make this work

so the content also will be downloaded through that proxy server, right ? i'm about traffic usage through proxy

yes sadly thats a big downside as residential IP bandwidth is very expensive. I pay like 8$ / gb. I use the service from oxylabs.io - it must be residential and support HTTP. Other types like HTTPS or SOCKS5 are not supported.

As an alternative you can set up a home proxy on some raspberry pi but the downside is that your IP will not change often

Got it, thanks dude. Better gonna reverse engineer the official instance API by bypassing Cloudflare 😅

@ubranch commented on GitHub (Apr 22, 2025): > > > guys the problem is with your datacenter IPs getting blocked because they are not what every day people use at home. You need a residential IP proxy to make this work > > > > > > so the content also will be downloaded through that proxy server, right ? i'm about traffic usage through proxy > > yes sadly thats a big downside as residential IP bandwidth is very expensive. I pay like 8$ / gb. I use the service from oxylabs.io - it must be residential and support HTTP. Other types like HTTPS or SOCKS5 are not supported. > > As an alternative you can set up a home proxy on some raspberry pi but the downside is that your IP will not change often Got it, thanks dude. Better gonna reverse engineer the official instance API by bypassing Cloudflare 😅
Author
Owner

@wukko commented on GitHub (Apr 23, 2025):

Better gonna reverse engineer the official instance API by bypassing Cloudflare 😅

you’re not able to do that lmfao good luck

@wukko commented on GitHub (Apr 23, 2025): > Better gonna reverse engineer the official instance API by bypassing Cloudflare 😅 you’re not able to do that lmfao good luck
Author
Owner

@ubranch commented on GitHub (Apr 23, 2025):

Better gonna reverse engineer the official instance API by bypassing Cloudflare 😅

you’re not able to do that lmfao good luck

how the fuck do you think you know what I'm capable of, LMFAO? take your pathetic assumptions and shove your fake-ass good luck straight up your sorry ass, bro.

@ubranch commented on GitHub (Apr 23, 2025): > > Better gonna reverse engineer the official instance API by bypassing Cloudflare 😅 > > you’re not able to do that lmfao good luck how the fuck do you think you know what I'm capable of, LMFAO? take your pathetic assumptions and shove your fake-ass good luck straight up your sorry ass, bro.
Author
Owner

@crackticker commented on GitHub (Apr 23, 2025):

Better gonna reverse engineer the official instance API by bypassing Cloudflare 😅

you’re not able to do that lmfao good luck

how the fuck do you think you know what I'm capable of, LMFAO? take your pathetic assumptions and shove your fake-ass good luck straight up your sorry ass, bro.

are you capable of sucking my balls or do u need claude 3.5 for that

@crackticker commented on GitHub (Apr 23, 2025): > > > Better gonna reverse engineer the official instance API by bypassing Cloudflare 😅 > > > > you’re not able to do that lmfao good luck > > how the fuck do you think you know what I'm capable of, LMFAO? take your pathetic assumptions and shove your fake-ass good luck straight up your sorry ass, bro. > > are you capable of sucking my balls or do u need claude 3.5 for that
Author
Owner

@wukko commented on GitHub (Apr 23, 2025):

Better gonna reverse engineer the official instance API by bypassing Cloudflare 😅

you’re not able to do that lmfao good luck

how the fuck do you think you know what I'm capable of, LMFAO? take your pathetic assumptions and shove your fake-ass good luck straight up your sorry ass, bro.

not sure what you get from your embarrassing whining, but you’re one of the dumbest people i’ve seen in our issues yet. have fun, and i hope you grow out of being a useless poser eventually :)

@wukko commented on GitHub (Apr 23, 2025): > > > Better gonna reverse engineer the official instance API by bypassing Cloudflare 😅 > > > > > > you’re not able to do that lmfao good luck > > how the fuck do you think you know what I'm capable of, LMFAO? take your pathetic assumptions and shove your fake-ass good luck straight up your sorry ass, bro. not sure what you get from your embarrassing whining, but you’re one of the dumbest people i’ve seen in our issues yet. have fun, and i hope you grow out of being a useless poser eventually :)
Author
Owner

@ubranch commented on GitHub (Apr 23, 2025):

Better gonna reverse engineer the official instance API by bypassing Cloudflare 😅

you’re not able to do that lmfao good luck

ofc i can't 👍 🤡
Image

@ubranch commented on GitHub (Apr 23, 2025): > > Better gonna reverse engineer the official instance API by bypassing Cloudflare 😅 > > you’re not able to do that lmfao good luck ofc i can't 👍 🤡 ![Image](https://github.com/user-attachments/assets/cc68eef7-cf6a-42b1-86a4-c09e6293b13d)
Author
Owner

@wukko commented on GitHub (Apr 23, 2025):

ofc i can't 👍 🤡

good job at putting a one-time solution token into a http request! you’re not bypassing turnstile though :(

@wukko commented on GitHub (Apr 23, 2025): > ofc i can't 👍 🤡 good job at putting a one-time solution token into a http request! you’re not *bypassing* turnstile though :(
Author
Owner

@ansharyan03 commented on GitHub (Apr 25, 2025):

guys the problem is with your datacenter IPs getting blocked because they are not what every day people use at home. You need a residential IP proxy to make this work

so the content also will be downloaded through that proxy server, right ? i'm about traffic usage through proxy

yes sadly thats a big downside as residential IP bandwidth is very expensive. I pay like 8$ / gb. I use the service from oxylabs.io - it must be residential and support HTTP. Other types like HTTPS or SOCKS5 are not supported.

As an alternative you can set up a home proxy on some raspberry pi but the downside is that your IP will not change often

i set up my cobalt api as an AWS ECS service and passed the oxylabs residential proxy URL into API_EXTERNAL_PROXY but now it gives me a fetch failed error. Am I missing something? If it helps, I have auth turned off but only because the URL to my instance is only exposed through a private DNS namespace.

Image

My cobalt container logs are empty, this is the response I'm getting from the cobalt container when calling it in my FastAPI script.

@ansharyan03 commented on GitHub (Apr 25, 2025): > > > guys the problem is with your datacenter IPs getting blocked because they are not what every day people use at home. You need a residential IP proxy to make this work > > > > > > so the content also will be downloaded through that proxy server, right ? i'm about traffic usage through proxy > > yes sadly thats a big downside as residential IP bandwidth is very expensive. I pay like 8$ / gb. I use the service from oxylabs.io - it must be residential and support HTTP. Other types like HTTPS or SOCKS5 are not supported. > > As an alternative you can set up a home proxy on some raspberry pi but the downside is that your IP will not change often i set up my cobalt api as an AWS ECS service and passed the oxylabs residential proxy URL into API_EXTERNAL_PROXY but now it gives me a fetch failed error. Am I missing something? If it helps, I have auth turned off but only because the URL to my instance is only exposed through a private DNS namespace. ![Image](https://github.com/user-attachments/assets/c2093f6d-0b3f-4eba-934d-0e3309a47d3c) My cobalt container logs are empty, this is the response I'm getting from the cobalt container when calling it in my FastAPI script.
Author
Owner

@elkofy commented on GitHub (May 4, 2025):

🍿 🍿 🍿

@elkofy commented on GitHub (May 4, 2025): 🍿 🍿 🍿
Sign in to join this conversation.