Indy TIdHTTP URI，登录/密码不工作 [英] Indy TIdHTTP URI with login/password not working
问题描述
我正在撰写一个 HTTP API封装，以便与特定 IP摄像机。该过程的一部分需要URI中的登录凭据，例如：
http：// user：pass_with _＃_ sign @ address： port / somespecificpath /
我正在使用Indy的 TIdHTTP.Get 将请求发送到设备。但是，密码由'＃'字符组成。如果该URI被放置在任何具有纯密码的浏览器中，则＃字符将抛出它。因此，我需要将密码＃编码到％23 ...
http：// user：pass_with_％23_sign @ address：port / somespecificpath /
当我将该URI粘贴到任何浏览器中时，它成功登录并执行所需的操作。但是，当我将完全相同的URI传递到 TIdHTTP.Get 中时，它不会成功登录，因此只要密码包含＃（或％23 ）。将密码更改为不包含＃的解决方案太草率了。 Indy必须用这个URI /密码来解决问题。
这是Indy中的一个错误，还是有其他一些我需要做的，让Indy接受这样一个编码密码？
更新
我在其中一个摄像机上添加了一个用户名和密码的新帐号，没有任何需要编码的特殊字符，认证仍然不起作用。看起来好像Indy完全从URI剥离了登录凭据，甚至没有发送这些凭据。接下来我需要做的是监控实际发送的URI。
更新2
我通过WireShark做了一个数据包捕获，并验证了凭据 ... user：pass @ ... 甚至没有发送 - 他们被从Indy实际发送的URI剥离。
更新3
TLama建议我捕获使用浏览器时发送的内容。我尝试了这一点，即使使用浏览器，捕获也不会显示这些登录凭据，即使它可以从浏览器工作。所以我必须找出另一种方式来确定是否发送这些凭据。
更新4
我尝试（在看到Remy的答案之前）在 Request.Username 和 Request.Password 而不是在URI中，我还没有成功。我从设备中恢复未经授权。
更新5
此API的文档提到与本款不同的用户认证无关：
Grandstream视频监控API（应用程序编程接口）支持HTTP 1.0协议（RFC1945）。本文档通过支持的GET / POST方法详细说明了客户端功能的参数。用户将需要管理员权限才能检索或设置参数。
在这个说明中，我将 TIdHTTP 协议版本切换到 1.0 。
更新6 / p>
希望最后一次更新需要...我对浏览器（Chrome）和 TIdHTTP 。 Chrome实际上发送两个请求，第一个没有任何凭据，但在第二个请求中，标题 Authorization：Basic ... 和凭证：用户：通过，而使用 TIdHTTP 只发送1个单独的请求，而没有这些凭据。
更新7
7是一个幸运数字:-)我只是意识到，我对设备的第一个请求返回未经授权，但所有以下请求（使用相同的 TIdHTTP 实例）成功！所以回到我以前的更新，就像我在浏览器捕获中看到的那样，它需要第二个重复的请求来工作。
我已经通过发送两个连续的 Get 请求来解决问题。在观察浏览器和Indy之间的数据包捕获后，我注意到浏览器将始终发送一个没有凭证的请求，然后再发送一个具有凭证的相同请求。所以只需要发送凭证即可。 Indy只发送一个请求，但是如果我之后发送另一个请求，我有成功。
所以，请求现在看起来像...
FWeb.Get（U）;
FWeb.Get（U，R）;
当然这应该是按照如果第一个请求是未经授权的，那么再发送另一个请求凭证。
I'm writing an HTTP API wrapper to integrate with particular IP Cameras. Part of the process requires login credentials in the URI, for example:
http://user:pass_with_#_sign@address:port/somespecificpath/
I'm using Indy's TIdHTTP.Get to send the request to the device. However, the password consists of a '#' character. If this URI is placed in any browser with the plain password, the # character throws it off. Therefore, I need to encode the password's # to %23...
http://user:pass_with_%23_sign@address:port/somespecificpath/
When I paste this URI into any browser, it successfully logs in and does what it needs. However, when I pass the exact same URI into TIdHTTP.Get, it does not successfully log in, and therefore I cannot do anything as long as the password contains # (or %23). Changing the password to not include a # is far too sloppy of a solution. Indy must be messing something up with this URI/password.
Is this a bug in Indy, or is there something else I need to do to make Indy accept such an encoded password?
UPDATE
I added a new account on one of the cameras with username and password without any special characters which need encoding, and authentication still does not work. It seems as if Indy is stripping out the login credentials completely from the URI, and doesn't even send these credentials. Next thing I need to do is monitor the URI which is actually sent.
UPDATE 2
I did a packet capture via WireShark and have verified that the credentials ...user:pass@... are not even sent - they're stripped from the URI that Indy actually sends.
UPDATE 3
TLama suggested that I get a capture of what's sent when using a browser. I tried this, and sure enough even when using a browser the capture doesn't show these login credentials either... even though it works from a browser. So I have to figure out another way to identify whether or not these credentials are sent.
UPDATE 4
I tried (before seeing Remy's answer) to provide these credentials in Request.Username and Request.Password instead of in the URI, and I still have no success. I keep getting "Unauthorized" back from the device.
UPDATE 5
The documentation for this API mentions nothing relevant to how users are authenticated other than this paragraph:
Grandstream Video Surveillance API (Application Programming Interface) supports HTTP 1.0 protocol (RFC1945). This document explains in detail the parameter of functions in client side, via the supported GET/POST method. Users will require administrator privilege to retrieve or set the parameters.
And on that note, I did switch the TIdHTTP protocol version to 1.0.
UPDATE 6
Hopefully the last update needed... I did another comparison with the packet captures between a browser (Chrome) and TIdHTTP. Chrome actually sends two requests, the first one does not have any credentials, but in the second request there's a node in the header Authorization: Basic... and Credentials: User:Pass, whereas using TIdHTTP only sends 1 single request without these credentials.
UPDATE 7
7 is a lucky number :-) I just realized, the very first request I make to the device returns "Unauthorized", but all following requests I make (using the same TIdHTTP instance) are successful! So going back to my prior update, just like I see in the browser capture, it takes that second repetitive request for it to work.
I have solved the issue by sending two sequential Get requests. After observing the packet captures between a browser and Indy, I noticed browsers would always send one request without credentials, and then another identical request with credentials. So it only sends the credentials when it needs to. Indy was only sending one request, but if I send another request right afterward, I have success.
So, the request now looks like...
FWeb.Get(U);
FWeb.Get(U, R);
Of course it really should be in the order of "If the first request is unauthorized, then send another request with credentials".
这篇关于Indy TIdHTTP URI，登录/密码不工作的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
