调整session请求API

[Geeksun2018]

我在本地测试了许多jellyfin版本，发现所有版本都不支持现在的session请求方式。于是我根据抓包分析出jellyfin最新版本的sessionapi，并调整了请求结构，测试了几个版本，应该没有问题。

[Izumiko]

我的请求方式照着控制台的写的，自己用着倒是没啥问题。你有测试过删除session的查询参数之后，在多用户/多设备的情况下，能正确获取正在播放条目么？

[Geeksun2018]

我的请求方式照着控制台的写的，自己用着倒是没啥问题。你有测试过删除session的查询参数之后，在多用户/多设备的情况下，能正确获取正在播放条目么？

上面两张图分别是之前的session请求接口，和现在我修改过的session请求接口。其实最根本的区别就是新的这版没有带参数了，校验用户信息是通过请求头中的X-Emby-Authorization字段，这里面就包含了DeviceId之类的信息。我不太确定是不是新版本修改了session的请求接口导致无法通过原来的接口获取session信息，但是我在本地部署了某些老版本的jellyfin，我发现在我的机器上均无法通过之前的接口正确获取。所以我还不太确定到底是什么原因造成的这个问题。请问你在本地是哪个版本的jellyfin呢？是通过docker部署的还是？我现在的环境里面是有两个用户，但是我还不确定他们同时播放是否会有问题，我这次的修改并没有对代码逻辑有太大的改动，应该不会影响到多用户的情况。我明天晚上会测试一下多端多账号同时登录的情况，看看是否存在问题。

[Geeksun2018]

我的请求方式照着控制台的写的，自己用着倒是没啥问题。你有测试过删除session的查询参数之后，在多用户/多设备的情况下，能正确获取正在播放条目么？

我的请求也是从控制台中抓取的，不过我刚刚试了下，客户端获取session的情况很少触发啊，刚刚都没有抓到。你抓到的应该是脚本发的请求，可能新版本客户端请求的格式变化了些。

[Izumiko]

我是Docker部署的jellyfin/jellyfin:latest，现在也是10.8.12版。然后用nginx代理到/jellyfin路径下，通过https访问。 另外X-Emby-Authorization应该已经弃用了，新的使用Authorization（虽然两个的内容是一样的）。官方的接口文档

[Izumiko]

我前边截图那个确实是脚本发的，客户端获取session会在网页打开时获取一次

[Geeksun2018]

我是Docker部署的jellyfin/jellyfin:latest，现在也是10.8.12版。然后用nginx代理到/jellyfin路径下，通过https访问。 另外X-Emby-Authorization应该已经弃用了，新的使用Authorization（虽然两个的内容是一样的）。官方的接口文档

那我们的版本完全一样了，这个接口文档我也看了，确实是弃用了，但是我搞不懂为什么我的这个客户端还在用这种方式来请求。 好奇怪。。。为啥两个环境都一样，请求方式差别却这么大。

[Izumiko]

哦对了，在baseurl网址后边加上/api-docs/swagger能访问本地Jellyfin的API页面

[Izumiko]

我是Docker部署的jellyfin/jellyfin:latest，现在也是10.8.12版。然后用nginx代理到/jellyfin路径下，通过https访问。 另外X-Emby-Authorization应该已经弃用了，新的使用Authorization（虽然两个的内容是一样的）。官方的接口文档

那我们的版本完全一样了，这个接口文档我也看了，确实是弃用了，但是我搞不懂为什么我的这个客户端还在用这种方式来请求。 好奇怪。。。为啥两个环境都一样，请求方式差别却这么大。

估计Jellyfin Web那里还没来及改吧，我这里客户端实际用的也是旧版，只有API文档里面用的是新的

[Geeksun2018]

我前边截图那个确实是脚本发的，客户端获取session会在网页打开时获取一次

我

我是Docker部署的jellyfin/jellyfin:latest，现在也是10.8.12版。然后用nginx代理到/jellyfin路径下，通过https访问。 另外X-Emby-Authorization应该已经弃用了，新的使用Authorization（虽然两个的内容是一样的）。官方的接口文档

那我们的版本完全一样了，这个接口文档我也看了，确实是弃用了，但是我搞不懂为什么我的这个客户端还在用这种方式来请求。 好奇怪。。。为啥两个环境都一样，请求方式差别却这么大。

估计Jellyfin Web那里还没来及改吧，我这里客户端实际用的也是旧版，只有API文档里面用的是新的

可能是这样子吧，昨天有个网友也是和我一样的情况，无法获取session。我们该怎么知道在不同的环境中应该用哪种请求方式呢？或者说有没有什么通用的办法能兼容不同的环境，昨天我想通过版本号来区分不同的请求方式，但是当我降低jellyfin的版本后，我发现我还是只能通过X-Emby-Authorization这种方式来获取session。

[Izumiko]

我前边截图那个确实是脚本发的，客户端获取session会在网页打开时获取一次

我

我是Docker部署的jellyfin/jellyfin:latest，现在也是10.8.12版。然后用nginx代理到/jellyfin路径下，通过https访问。 另外X-Emby-Authorization应该已经弃用了，新的使用Authorization（虽然两个的内容是一样的）。官方的接口文档

那我们的版本完全一样了，这个接口文档我也看了，确实是弃用了，但是我搞不懂为什么我的这个客户端还在用这种方式来请求。 好奇怪。。。为啥两个环境都一样，请求方式差别却这么大。

估计Jellyfin Web那里还没来及改吧，我这里客户端实际用的也是旧版，只有API文档里面用的是新的

可能是这样子吧，昨天有个网友也是和我一样的情况，无法获取session。我们该怎么知道在不同的环境中应该用哪种请求方式呢？或者说有没有什么通用的办法能兼容不同的环境，昨天我想通过版本号来区分不同的请求方式，但是当我降低jellyfin的版本后，我发现我还是只能通过X-Emby-Authorization这种方式来获取session。

Jellyfin没Emby那个PluginManager真是麻烦，只能迂回地获取正在播放项目。。。要是你后边测试多用户或多设备同时播放没问题的话，那就先用你这一版吧，至少能兼容低版本？

[Geeksun2018]

我前边截图那个确实是脚本发的，客户端获取session会在网页打开时获取一次

我

我是Docker部署的jellyfin/jellyfin:latest，现在也是10.8.12版。然后用nginx代理到/jellyfin路径下，通过https访问。 另外X-Emby-Authorization应该已经弃用了，新的使用Authorization（虽然两个的内容是一样的）。官方的接口文档

那我们的版本完全一样了，这个接口文档我也看了，确实是弃用了，但是我搞不懂为什么我的这个客户端还在用这种方式来请求。 好奇怪。。。为啥两个环境都一样，请求方式差别却这么大。

估计Jellyfin Web那里还没来及改吧，我这里客户端实际用的也是旧版，只有API文档里面用的是新的

可能是这样子吧，昨天有个网友也是和我一样的情况，无法获取session。我们该怎么知道在不同的环境中应该用哪种请求方式呢？或者说有没有什么通用的办法能兼容不同的环境，昨天我想通过版本号来区分不同的请求方式，但是当我降低jellyfin的版本后，我发现我还是只能通过X-Emby-Authorization这种方式来获取session。

Jellyfin没Emby那个PluginManager真是麻烦，只能迂回地获取正在播放项目。。。要是你后边测试多用户或多设备同时播放没问题的话，那就先用你这一版吧，至少能兼容低版本？

OK的，我这几天花时间多测试一下。

[Xarth-Mai]

奇怪捏 我这边运行良好🥲

[Geeksun2018]

奇怪捏 我这边运行良好🥲

是的，暂时还不知道为什么目前这种请求方式为什么会导致无法收到response，不过新的这个版本测试了是没问题的，有空我去看看jellyfin服务端的代码。

[Geeksun2018]

我前边截图那个确实是脚本发的，客户端获取session会在网页打开时获取一次

我

我是Docker部署的jellyfin/jellyfin:latest，现在也是10.8.12版。然后用nginx代理到/jellyfin路径下，通过https访问。 另外X-Emby-Authorization应该已经弃用了，新的使用Authorization（虽然两个的内容是一样的）。官方的接口文档

那我们的版本完全一样了，这个接口文档我也看了，确实是弃用了，但是我搞不懂为什么我的这个客户端还在用这种方式来请求。 好奇怪。。。为啥两个环境都一样，请求方式差别却这么大。

估计Jellyfin Web那里还没来及改吧，我这里客户端实际用的也是旧版，只有API文档里面用的是新的

可能是这样子吧，昨天有个网友也是和我一样的情况，无法获取session。我们该怎么知道在不同的环境中应该用哪种请求方式呢？或者说有没有什么通用的办法能兼容不同的环境，昨天我想通过版本号来区分不同的请求方式，但是当我降低jellyfin的版本后，我发现我还是只能通过X-Emby-Authorization这种方式来获取session。

Jellyfin没Emby那个PluginManager真是麻烦，只能迂回地获取正在播放项目。。。要是你后边测试多用户或多设备同时播放没问题的话，那就先用你这一版吧，至少能兼容低版本？

OK的，我这几天花时间多测试一下。

我这边测试了多端同时播放没有问题，不过测试了时候发现了一些其他问题，在新的版本修复了。你抽空的时候也帮忙测试一下哈，没问题的话就可以合并PR了哈。

[Xarth-Mai]

我这边测试了多端同时播放没有问题，不过测试了时候发现了一些其他问题，在新的版本修复了。你抽空的时候也帮忙测试一下哈，没问题的话就可以合并PR了哈。

总觉得你那个代码有点抽象 为什么要硬编码一个UA 这应该不必要且存在潜在问题

[Geeksun2018]

我这边测试了多端同时播放没有问题，不过测试了时候发现了一些其他问题，在新的版本修复了。你抽空的时候也帮忙测试一下哈，没问题的话就可以合并PR了哈。

总觉得你那个代码有点抽象 为什么要硬编码一个UA 这应该不必要且存在潜在问题

直接把控制台请求复制过来了hhh，感谢！这就修改一下。（后端程序员硬写前端）

[Xarth-Mai]

感觉还是原来的实现方式更接近Web端其他原生流量

[Geeksun2018]

感觉还是原来的实现方式更接近Web端其他原生流量

确实是，我们之前讨论过jellyfin文档中提到的sessions接口，确实是按照现在的规范构造请求的。但是我在本地抓包的地方，发现web端实际的请求方式和接口文档中并不相同，而且某些客户端无法用文档中的方式正确请求。可能还得再研究研究服务端这边到底怎么处理请求的。

[Xarth-Mai]

感觉还是原来的实现方式更接近Web端其他原生流量

确实是，我们之前讨论过jellyfin文档中提到的sessions接口，确实是按照现在的规范构造请求的。但是我在本地抓包的地方，发现web端实际的请求方式和接口文档中并不相同，而且某些客户端无法用文档中的方式正确请求。可能还得再研究研究服务端这边到底怎么处理请求的。

大多是从Emby fork过来的历史遗留问题,按照新的写法就行

[Geeksun2018]

找到问题了！我用二级域名去访问jellyfin就会导致校验失败，如果直接通过ip+端口号是没问题的。 解决办法是修改我的proxy.conf为下面的内容

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header X-Forwarded-Port $server_port;
proxy_pass $forward_scheme://$server:$port;```

[Geeksun2018]

找到问题了！我用二级域名去访问jellyfin就会导致校验失败，如果直接通过ip+端口号是没问题的。 解决办法是修改我的proxy.conf为下面的内容

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header X-Forwarded-Port $server_port;
proxy_pass $forward_scheme://$server:$port;

@Izumiko @Xarth-Mai 感谢二位！

[Izumiko]

找到问题了！我用二级域名去访问jellyfin就会导致校验失败，如果直接通过ip+端口号是没问题的。 解决办法是修改我的proxy.conf为下面的内容

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_set_header X-Forwarded-Host $http_host;
proxy_set_header X-Forwarded-Port $server_port;
proxy_pass $forward_scheme://$server:$port;```

我用的Caddy，配置起来省事点

hostname {
    tls
    reverse_proxy /jellyfin/* localhost:8096
}

[Xarth-Mai]

#8