我发现可以通过JavaScript API完成DockerHub存储库的full_description的编辑，并且发现这是学习python的requests软件包的有趣借口。 JavaScript API绝对有效，例如使用this simple docker image。
JS API基本上可以做到
POST request至https://hub.docker.com/v2/users/login，以及用户名和密码。服务器以token响应。PATCH request到特定的https://hub.docker.com/v2/repositories/{user or org}/{repo}，确保标头具有Authorization: JWT {token}，在这种情况下，其内容主体为{"full_description":"...value..."}。令人不安的是，python端的PATCH请求从服务器返回了200响应（如果您有意设置了错误的身份验证令牌，则会如预期那样被拒绝）。但是它的响应实际上包含当前信息（不是修补的信息）。
我所做的唯一“发现”：
如果添加debug logging stuff，则会出现301。但这与javascript端的URL是相同的，所以没关系吗？
send: b'{"full_description": "TEST"}'
reply: 'HTTP/1.1 301 MOVED PERMANENTLY\r\n'
在这不是事实。它们是不同的，我不知道我怎么认为它们是相同的。POST中执行requests所收到的令牌与{{3}中所述的我GET至auth.docker.io相同}。 值得注意的是，我没有指定密码（curl -X GET ...也没有指定密码）。
第二个让我觉得我好像错过了一步。像我需要解码令牌或什么？我不知道该怎么做，尤其是200的{{1}}响应，尽管没有任何变化。
代码：
PATCH答案 0 :(得分：1)
使用request.Session（）时与CSRF问题有关的其他信息：
在这种情况下，发出请求时，Docker Hub似乎无法识别csrftoken命名的标头/ cookie（即将到来的cookie的默认名称）。
相反，在以下请求上使用标头X-CSRFToken时，CSRF被标识为有效。
也许是cookie-to-header token pattern.
使用登录响应的cookie更新会话标头
s.headers.update({"X-CSRFToken": s.cookies.get("csrftoken")})
不再需要为进一步的请求手动设置JWT令牌-令牌已作为cookie工作。
对不起，没有足够的特权可以发表评论，但是我认为这已经足够相关了。
答案 1 :(得分：0)
事实证明，JWT {token}身份验证在整个时间都是有效的。显然，您需要在URL的末尾加上/。没有它，什么都不会发生。大声笑！
# ----------------------------------------------------V
repo_url = f"{base_url}/repositories/{username}/{repo}/"
如预期的那样，PATCH然后以更新的描述而不是旧的描述进行响应。哇！
重要说明：自2020年1月15日起，这对我有效，但是在我的追求中，我遇到了this dockerhub issue，这似乎表明如果您的帐户启用了2FA，则无法再编辑{ {1}}使用description请求。我的帐户中没有2FA，因此可以（显然）。目前尚不清楚它的未来。
相关说明：JWT令牌在整个时间内一直保持不变，因此对于像我这样的网络新手，请不要共享这些;）