[self-hosted] Tunnels issue

[sertraline]

bug description

This is an issue I already solved but I decided to write it out anyway, as it may (or may not) be helpful to anyone.

I host my own instance, which is cv.acid.im. I only use the API (no web interface). Recently I've updated cobalt and tiktok downloads stopped working. The response I get on the tiktok URL is similar to this:
{'status': 'tunnel', 'url': 'https://cv.acid.im/tunnel?id=tfeuXyLs5iNdlh_NDgaoi&exp=1728241112610&sig=UFmTDfBXuSrprTY7WSM7L2XC185UctcRqd8wLE9uPXM&sec=lDzitidp6YAmETr4QVOIh1_mFTw4Cq7kaIiJHRJZTOY&iv=3yEEJn3c2oNFHvid3YIesA', 'filename': 'tiktok_4wheeltest_7409257742071827744.mp4'}

which looks fine. If you try to go by that URL, however, this is what you get:

When I try to curl or wget it, I get 403 forbidden (does not matter if API_URL is set to localhost and I wget from localhost). Why?

curl https://cv.acid.im/tunnel\?id\=wzvloQAZ0Rtn4La0n-lbB\&exp\=1728241745042\&sig\=McMw_Ah5rGR9r9SyOEZQOQCfgk5CQC_gr-Xj69BvMoA\&sec\=fwzax4NseN5yNHI5Bn-VAaJ7q4dri3d2-gP9wcYbJWw\&iv\=O94hjuYSwXoRyNdqQlCGlQ
Forbidden# 

I tried to log the responses it gives.
This is what I get from the tiktok service:

return https://v16-webapp-prime.tiktok.com/video/tos/useast2a/tos-useast2a-ve-0068-euttp/oIRPPJgA8pAWAQeeGnGnZS86f6MzNEPRQAObel/?a=1988&bti=ODszNWYuMDE6&ch=0&cr=3&dr=0&lr=all&cd=0%7C0%7C0%7C&cv=1&br=2840&bt=1420&cs=0&ds=6&ft=-Csk_mIRPD12NwA.uE-UxqT2SYKW3wv25McAp&mime_type=video_mp4&qs=0&rc=aDU3ODo3NTRlNTQ7NGc7NEBpMzxpdW05cmtpdTMzZjczM0BiYWJgMDUuNTIxLjVeNWEtYSNsNWg0MmQ0YjZgLS1kMWNzcw%3D%3D&btag=e00088000&expire=1728263260&l=202410061907162FA9263FBF5E992FAF73&ply_type=2&policy=2&signature=7fe024af02e4406d51596bc0c7989cc9&tk=tt_chain_token tiktok_4wheeltest_7409257742071827744.mp4 
Cookie {
  _values: {
    ttwid: ...
  }
}

StreamInfo also seems to be valid when I access it:

streamInfo: {
  exp: 1728241745042,
  type: 'proxy',
  urls: 'http://127.0.0.1:9191/itunnel?id=xCVBM1OA94ErcUVTmbj4G',
  service: 'tiktok',
  filename: 'tiktok_4wheeltest_7409257742071827744.mp4',
  headers: {
    cookie: ...
  },
  metadata: false,
  audioCopy: false,
  range: undefined
}

My nginx config is just a reverse proxy pointing to localhost:

server {
        listen 80;
        listen 443 ssl;
        server_name cv.acid.im;

        root /var/www/html;

        ssl_certificate /etc/letsencrypt/live/acid.im/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/acid.im/privkey.pem;
        location / {
                proxy_pass http://127.0.0.1:9191;
                proxy_set_header Host $host;
        }
}

So, by all means it should be working properly. Being given 403 by curl or wget, I decided to go to api/src/core/api.js and disable the offending lines:

    app.get('/itunnel', (req, res) => {
        //if (!req.ip.endsWith('127.0.0.1')) {
        //    console.log("> sent 403");
        //    return res.sendStatus(403);
        //}

With that, my instance works as supposed to. I don't think this was an intended behavior.

reproduction steps

1. git clone https://github.com/imputnet/cobalt
2. cd cobalt
3. pnpm install
4. export API_URL=https://cv.acid.im
5. node api/src/cobalt.js
6. curl -X POST "https://cv.acid.im" -H "Content-Type: application/json" -H "Accept: application/json" --data '{"url": "https://vm.tiktok.com/ZGdJuX9nW/", "videoQuality":"1440"}'

screenshots

No response

links

Example case: https://vm.tiktok.com/ZGdJuX9nW/
https://vm.tiktok.com/ZGdJuAH41/
https://www.tiktok.com/@mr.cattttttt/video/7422496821060062506

platform information

brave on linux mint

additional context

No response

[sertraline]

I figured this line is here because you access the tunnel URL with a web interface from within docker, so it only must be a 127.0.0.1 origin?

[lostdusty]

yes it should be 127.0.0.1

[sertraline]

Would it be possible to add an option to run a standalone API server so the URLs can be accessible from the outside network?

[dumbmoron]

With that, my instance works as supposed to. I don't think this was an intended behavior.

it is the intended behavior, because itunnels are supposed to be only accessible internally (e.g. via ffmpeg), and this change makes them accessible globally by anyone.

the correct solution would be to check what is contained within req.ip and add it to the condition (since I assume it's something other than 127.0.0.1 for whatever reason)

[wukko]

have you tried using docker instead?

[sertraline]

fine. I'll set up docker.