These are chat archives for IndySockets/Indy

6th
Sep 2017
Valmeras
@Valmeras
Sep 06 2017 00:10
It is an IP Camera. I am reinstalling my RAD Studio. I will check the event and let you know when I will ready
Ludwig Behm
@lbehm
Sep 06 2017 10:20
Hy, can someone tell me which bpi I have to link to access IdHTTPWebBrokerBridge?
Ludwig Behm
@lbehm
Sep 06 2017 10:57
if I try #pragma link "IdHTTPWebBrokerBridge" I get the Error:
[ilink64 Error] Error: Unit 'Web.webbroker' is marked with deny package
Does someone know how to solve/debug this?
Ludwig Behm
@lbehm
Sep 06 2017 14:07
major detail: I attempted static linking
Valmeras
@Valmeras
Sep 06 2017 15:06
I used the code below to try to determine the type of authentication:
UnicodeString IPProtocole;

for (int indice = 0; indice < AuthInfo->Count; indice++)
{
    IPProtocole = AuthInfo->Strings[indice];

    IWMemo1->Lines->Add(IPProtocole);
  }
This is for the OnSelectAuthorization event.
I tried with 2 different Cameras. The first one gave qop="auth" and the second one nothing: empty result. How can I find the right authentication to connect?
Remy Lebeau
@rlebeau
Sep 06 2017 17:21
@devimplode IdHTTPWebBrokerBridge.pas is a standalone unit, it is not implemented in any package. Just add the .pas file to your WebBroker project.
Remy Lebeau
@rlebeau
Sep 06 2017 17:28
@Valmeras The AuthInfo parameter should be whatever the IP camera sends in its WWW-Authenticate HTTP response header(s). qop="auth" by itself is not valid for the WWW-Authenticate header. It should be a sub-attribute in a WWW-Authenticate: Digest ... header, for instance. What do the raw HTTP response headers actually look like? It should look something like this: WWW-Authenticate: Digest realm="...", qop="auth", nonce="...", opaque="..."
Valmeras
@Valmeras
Sep 06 2017 17:29
Below is the exact response from the IP Camera:
Digest realm="IPCamera Login", nonce="aab73c7dd16e42dce529249f19cd9b73", qop="auth"
Remy Lebeau
@rlebeau
Sep 06 2017 17:30
@Valmeras That entire string should appear in the AuthInfo parameter. Are you saying it doesn't?
@Valmeras In any case, the camera is clearly using Digest authentication, so add the IdAuthenticationDigest unit to your uses clause
Valmeras
@Valmeras
Sep 06 2017 17:31
This is the exact response from the first IP Camera. The second one is an empty response. I will double-check.
Remy Lebeau
@rlebeau
Sep 06 2017 17:32
@Valmeras the only way AuthInfo would be empty is if the camera is not sending any WWW-Authenticate header, or is sending a blank one. Either way is invalid for an HTTP 401 response that asks the client for authentication. What does the complete response look like?
Valmeras
@Valmeras
Sep 06 2017 17:46
I checked again and the response from the 2nd camera is totally blank. Nothing.
Remy Lebeau
@rlebeau
Sep 06 2017 18:07
@Valmeras again, what does the raw HTTP response look like? The entire response, not just the WWW-Authenticate header. The response cannot be completely blank
Valmeras
@Valmeras
Sep 06 2017 18:09
I confirm that it is empty. Nothing. Blank
Remy Lebeau
@rlebeau
Sep 06 2017 18:14
@Valmeras That is simply not possible. That would break the HTTP protocol, not to mention that it would prevent TIdHTTP from firing the OnSelectAuthorization event. It has to be a valid 401 reply to get that far. I need to see the RAW DATA that the camera is actually sending in reply to your TIdHTTP request
Valmeras
@Valmeras
Sep 06 2017 18:16
How can I get that raw data? The solution I found was the code above using OnSelectAuthorization. Is there another solution?
Remy Lebeau
@rlebeau
Sep 06 2017 18:17
@Valmeras Use a packet sniffer, like Wireshark, or assign one of Indy's TIdLog... components to the TIdHTTP.Intercept property. OnSelectAuthorization only applies specifically to the handling of the WWW-Authenticate header, not the entire reply as a whole. I need to see the entire reply.
Valmeras
@Valmeras
Sep 06 2017 18:47
I associated a TIdLogEvent to the TIdHttp intercept. Now, how can get the logs?
Remy Lebeau
@rlebeau
Sep 06 2017 18:56
@Valmeras TIdLogEvent has OnReceived and OnSent events that are fired when receiving/sending raw data, respectively. You would have to save the data somewhere. For this situation, I would probably use TIdLogFile instead and set it to write to a .txt file.
Valmeras
@Valmeras
Sep 06 2017 19:09
Do you have an email address I can send you the file?
This is one part of the header. I don't know if this what you are looking for:
Sent 06-Sep-2017 15:05:17: GET /cgi-bin/CGIProxy.fcgi?cmd=snapPicture2 HTTP/1.1<EOL>Host: 192.168.3.152:35000<EOL>Accept: text/html,application/xhtml+xml,application/xml;q=0.9,/;q=0.8<EOL>User-Agent: Mozilla/3.0 (compatible; Indy Library)<EOL><EOL>
Recv 06-Sep-2017 15:05:17: HTTP/1.1 200 OK<EOL>Content-Type: text/plain<EOL>Transfer-Encoding: chunked<EOL>Date: Wed, 06 Sep 2017 19:05:16 GMT<EOL>Server: lighttpd/1.4.35<EOL><EOL>33<EOL><CGI_Result><LF> <result>-2</result><LF></CGI_Result><LF><EOL>0<EOL><EOL>
Remy Lebeau
@rlebeau
Sep 06 2017 19:15
@Valmeras yes, that is what I'm looking for. That reply is not asking for any authentication, so the OnSelectAuthorization and OnAuthorization events would not be fired for it. Why do you think you need to authenticate with that camera? The response is not an image, though. It is a text reply, implying the CGI script possibly failed
Valmeras
@Valmeras
Sep 06 2017 19:17
Because it requires an authentication. But it is embedded in the Url. Otherwise it is rejected when I set up the username and password in TidHttp. This is what I am trying to fix.
Remy Lebeau
@rlebeau
Sep 06 2017 19:19
@Valmeras obviously, it doesn't require authentication, because the CGI server is not asking for any authentication. If it did, the reply code would be 401, but it is 200 in the above example. Did you ignore everything I told you earlier about how credentials in a URL are handled? THEY ARE NOT PART OF THE URL ITSELF. THEY ARE EXTRACTED AND REMOVED FROM THE URL BEFORE THE HTTP REQUEST IS SENT TO THE SERVER. THEY ARE NOT SENT TO THE SERVER UNLESS THE SERVER ASKS FOR THEM. In this case, the server is not asking for authentication, so there is no authentication performed.
Valmeras
@Valmeras
Sep 06 2017 19:23
What you have to understand is that I have mo idea what king or credentials will be embedded in the Url. For some cameras, it will be as I said before http://username:passord@
But for other, like the one you have the logs, it will be http://Ip address/...&username=&password=
So, they can be totally different. I am trying to find a general solution to connect
Remy Lebeau
@rlebeau
Sep 06 2017 19:25
@Valmeras you clearly do not understand how HTTP authentication actually works. What you just described are two completely different things. Only the first example uses HTTP-based authentication, the second example doesn't use HTTP authentication at all, it is actually an HTML-based webform login instead. There is no general solution to handle that second case, the parameters are dictated by whatever HTML defines the actual login webform. Unless you are authenticating with devices that have fixed fields you can code against. Otherwise, you will need something more dynamic
Ludwig Behm
@lbehm
Sep 06 2017 19:25
@rlebeau thanks, I'll consider it... in my last project (win32/not clang) I think I'd linked it somehow
Valmeras
@Valmeras
Sep 06 2017 19:30
Even if the second is a HTML webform login as you said, but is exactly an IP camera liek the first one. And as I said, I cannot have a fixed configuration because I have no idea what king of IP camera the end user will have
Ludwig Behm
@lbehm
Sep 06 2017 19:31
@rlebeau does any plans exist to implement openssl v1.1.x compatibility in a semi-near future?
Remy Lebeau
@rlebeau
Sep 06 2017 19:33
@Valmeras you have to know ahead of time what you are connecting to so you can code for it accordingly. If different cameras have different ways of logging in, you are going to need to have different configurations in your app. Have an option for HTTP authentication, and a separate option for URL parameters, and let the user consult their camera documentation and tell you which one you need to use.
@devimplode no ETA, but it is on the todo list: IndySockets/Indy#183
@Valmeras I have to step out for a bit, I'll be back later
Valmeras
@Valmeras
Sep 06 2017 22:03
Which header file includes OAuth authentication?
Remy Lebeau
@rlebeau
Sep 06 2017 23:10
@Valmeras None, because Indy does not implement OAuth yet. IndySockets/Indy#142
Valmeras
@Valmeras
Sep 06 2017 23:21
What are the authentications which are implemented now? And which headers include them?
Remy Lebeau
@rlebeau
Sep 06 2017 23:53
@Valmeras if you look at the various IdAuthentication... units that are available, you would see that Indy currently implements only Basic, Digest, NTLM, and Negotiate