Libcurl 在 cookie.txt 中正确写入 cookie
Libcurl doest write cookie correctly in cookie.txt
我正在两个软件之间设置 API link。在此过程中,我需要用 java 调用 APIs。
(请视我为新手)
在 Java 代码中实现 API 调用之前,我想通过制定有效的 cURL 调用在控制台中获得可靠的服务器响应。我面临以下问题:
我向服务器进行身份验证,其中 return 我存储在 cookie.txt 文件中的 cookie 文件以供将来交互。但是,cookie.txt 不包含任何会话信息。这是它的内容:
# Netscape HTTP Cookie File
# curl
# This file was generated by libcurl! Edit at your own risk.
当在不同的计算机上尝试相同的 cURL 请求时,它工作正常,并且包含用户和会话信息。我得出结论,这与我的 cURL 版本有关。但是,两台电脑都是运行相同的版本(我认为是最新的):
C:\Users\victor>curl --version
curl 7.55.1 (Windows) libcurl/7.55.1 WinSSL
Release-Date: 2017-11-14, security patched: 2019-11-05
在这一点上我不知道了。你能帮我看看我的环境有什么问题吗?
谢谢,
维克多
好的。我没有找到解决方案,但我找到了解决方法。
首先,我在我的 curl 请求中添加了一个 --dump-header header.txt
选项。这将创建一个 .txt 文件,其中包含要包含在后续经过身份验证的请求中的会话的所有详细信息。
接下来,使用 Java 文件和字符串操作,我处理了 header.txt 文件,以提取会话信息。然后我将会话信息解析为字符串并使用选项 -b myCookieString
重新 运行 我的 curl 请求,而不是 -b myCookieFile.txt
我知道对于一个如此微不足道的问题来说这听起来太复杂了,但我费了整整 2 天的时间才想出这个解决方案。
PS :要了解 myCookieString
的格式,请查看您的 header.txt 文件中的 Set-Cookie 行。
-- 编辑 --
问题已不再自行发生...卷曲和 cookies 运行 现在没有问题。奇怪...不过,上述解决方案将始终有效(对我而言)。
我正在两个软件之间设置 API link。在此过程中,我需要用 java 调用 APIs。 (请视我为新手)
在 Java 代码中实现 API 调用之前,我想通过制定有效的 cURL 调用在控制台中获得可靠的服务器响应。我面临以下问题:
我向服务器进行身份验证,其中 return 我存储在 cookie.txt 文件中的 cookie 文件以供将来交互。但是,cookie.txt 不包含任何会话信息。这是它的内容:
# Netscape HTTP Cookie File
# curl
# This file was generated by libcurl! Edit at your own risk.
当在不同的计算机上尝试相同的 cURL 请求时,它工作正常,并且包含用户和会话信息。我得出结论,这与我的 cURL 版本有关。但是,两台电脑都是运行相同的版本(我认为是最新的):
C:\Users\victor>curl --version
curl 7.55.1 (Windows) libcurl/7.55.1 WinSSL
Release-Date: 2017-11-14, security patched: 2019-11-05
在这一点上我不知道了。你能帮我看看我的环境有什么问题吗?
谢谢,
维克多
好的。我没有找到解决方案,但我找到了解决方法。
首先,我在我的 curl 请求中添加了一个 --dump-header header.txt
选项。这将创建一个 .txt 文件,其中包含要包含在后续经过身份验证的请求中的会话的所有详细信息。
接下来,使用 Java 文件和字符串操作,我处理了 header.txt 文件,以提取会话信息。然后我将会话信息解析为字符串并使用选项 -b myCookieString
重新 运行 我的 curl 请求,而不是 -b myCookieFile.txt
我知道对于一个如此微不足道的问题来说这听起来太复杂了,但我费了整整 2 天的时间才想出这个解决方案。
PS :要了解 myCookieString
的格式,请查看您的 header.txt 文件中的 Set-Cookie 行。
-- 编辑 --
问题已不再自行发生...卷曲和 cookies 运行 现在没有问题。奇怪...不过,上述解决方案将始终有效(对我而言)。