Delphi idWHOIS with Web proxy - delphi

Good day,
Please help with an example of how to use idWHOIS via a web proxy?
I want to make whois calls anonymously using free web proxies.
Why is it so simple with idHTTP component that have ProxyParams but with idWHOIS not?
I am really clueless :)
See my attempted code snipped:
procedure TForm2.Button2Click(Sender: TObject);
var
ProxyHTTP :TIdConnectThroughHttpProxy;
Proxy :TIdCustomTransparentProxy;
begin
ProxyHTTP := TIdConnectThroughHttpProxy.Create(Self);
Proxy := TIdCustomTransparentProxy.Create(Self);
Try
{ idIOHandler.TransparentProxy := Proxy;
Proxy.Host := 'whois.ausregistry.net.au';
Proxy.Port := StrToInt('43');
Proxy.IPVersion := ID_DEFAULT_IP_VERSION;
// Proxy.Connect(idIOHandler, edtProxy.Text, StrToInt(edtPort.Text), ID_DEFAULT_IP_VERSION);
// Proxy.Enabled;
Proxy.ChainedProxy := ProxyHTTP;
}
idIOHandler.TransparentProxy := ProxyHTTP;
ProxyHTTP.Host := edtProxy.Text;
ProxyHTTP.Port := StrToInt(edtPort.Text);
ProxyHTTP.IPVersion := ID_DEFAULT_IP_VERSION;
ProxyHTTP.OnStatus := ProxyHTTPOnStatus;
ProxyHTTP.Enabled;
ProxyHTTP.Connect(idIOHandler, edtProxy.Text, StrToInt(edtPort.Text), ID_DEFAULT_IP_VERSION);
Memo1.Clear;
Memo1.Update;
Memo1.Lines.Text := idWhois.WhoIs(edtDomain.Text + '.com.au');
Finally
idIOHandler.Close;
idWhois.Disconnect;
Proxy.Free;
ProxyHTTP := TIdConnectThroughHttpProxy.Create(Self);
End;
end;

1st of all - do you use whois or http protocol ?
there are native whois services working via their native protocol.
and there are WWW front-ends, that let you make whois requests and vew results in WWW browsers like MSIE (Microsoft Internet Explorer).
Obviously you should be able to connect to latter via HTTP-proxy.
WWW here is monicker for several related technologies used together: HTTP + SSL/TLS + WebDAV + HTML + CSS + JS, etc. So, HTTP proxy may be considered subset of HTTP which is subset of WWW
And not be able to connect to former, for whois is not part of WWW blob.
Same thing for example is with e-mail, which is out of WWW realm as well:
there are mail programs, connecting directly by IMAP/POP/SMTP protocols and corresponding ports,
and there are WWW front-ends like Yahoo and GMail that allow to view mails via MSIE. WWW access works via HTTP proxy, direct access is not HTTP and does not work.
Exception: some proxies allow pin-holling. That is treated as security hole and bad configuration, but nonetheless it is sometimes possbile via HTTP/SSL support command CONNECT. But usually it is not possible to connect to every ports but only to :80 and :443 ports. And it is extremely rare that whois protocol would be on that ports, only HTTP or HTTPS protocols. Some servers, like many messengers like Jabber, ICQ, GTalk, or like Skype super-nodes, intentionally misuse those ports :80 and :443 to provide their non-HTTP protocols, thus helping those program to cheat on HTTP Proxy and bypass NAT isolation. But i think you'd hardly find many whois servers doing this
Whoever, if you find poorly configured proxy or such specially-configured whois server, you would have chance to use it.
Otherwise you would only be ably to use idHTTP over existing WWW-front-ends to whois servers. Most DNS name registrars do provide them, so users could check the data using no special tools but only WWW browsers.
Google for "http proxy ssl connect pinholling" for more details about such use of HTTP proxy.
Google for "NAT Traversal" and "Proxy Tunelling" for more general concept.
Sometimes VPN techniques are [mis-]used to tunnel outside.
PS. this does not answer "how can i do it" - there is no 100% reliable way - but hopefully answers "Why is it so simple with idHTTP component that have ProxyParams but with idWHOIS not?".
I guess you'd meet the very same obstacles, if to us idSMTP or other e-mail components through HTTP proxy.
PPS. there are more generic kind of proxies - Socks Proxy - that should allow any TCP-class protocol to be forwarded. But they are very rare thing.

Related

What is the meaning of crossed https in url of sites

What is the meaning of https which is crossed by two horizontal lines in the website url ?
http (Hypertext Transfer Protocol) is a system for transmitting and receiving information across the Internet. It is a simple request, and a response procedure is followed on the internet so that information can be easily, accurately and quickly exchanged between servers and software's which are trying to access it.
HTTPS URLs begin with "https://" and use port 443 by default, whereas HTTP URLs begin with "http://" and use port 80 by default.

IdFTP.Connect via proxy server

Our Delphi application is trying to connect to our website via IdFTP on a client machine using a proxy server, and I always get a 'read timed out' message. I don't know how to fix it.
My code:
IdFTP1.Host :=Website_address;
IdFTP1.Username :=Website_user;
IdFTP1.Password :=Website_password;
IdFTP1.TransferType:=ftBinary;
IdFTP1.ProxySettings.ProxyType:=fpcmNone;
IdFTP1.ProxySettings.Host :=Proxy_server;
IdFTP1.ProxySettings.Port :=Proxy_port;
IdFTP1.ProxySettings.Username :=Proxy_username;
IdFTP1.ProxySettings.Password :=Proxy_password;
IdFTP1.Connect;
...which returns a 'read timed out' exception.
Having looked on the web for possible solutions, I have tried various combinations of the following with no joy (although there might be a combination that might work, I just don't really know what I'm doing):
IdFTP1.IOHandler :=TIdSSLIOHandlerSocketOpenSSL.Create
(IdFTP1);
IdFTP1.UseTLS :=utUseExplicitTLS;
IdFTP1.NATKeepAlive.UseKeepAlive:=True;
IdFTP1.NATKeepAlive.IdleTimeMS :=100000;
IdFTP1.DataPortProtection :=ftpdpsPrivate;
The frustrating thing is I can't test it on my machine, I have to compile a new version of the application, copy it to their machine, and then see if it works.
There is nothing complex about the installation on the client side as far as I can tell. They have given me the proxy host address, and the proxy username and password are blank.
Other bits of the application connect to the same website via HTTP and the proxy server, and this works perfectly. So my logic is that it can't be firewalls or anything like that.
IdHTTP1.HandleRedirects :=True;
IdHTTP1.ProxyParams.BasicAuthentication:=True;
IdHTTP1.ProxyParams.ProxyServer :=Proxy_server;
IdHTTP1.ProxyParams.ProxyPort :=Proxy_port;
IdHTTP1.ProxyParams.ProxyUsername :=Proxy_username;
IdHTTP1.ProxyParams.ProxyPassword :=Proxy_password;
I am using Delphi XE8.
They have created a virtual server for our testing, it runs Windows 7 64 bit.
Update
Remy, is this the right idea? One problem I am having is the TIdConnectThroughHttpProxy component, what must be in the uses clause for this? Delphi is not recognizing it.
var
TempIO : TIdIOHandlerStack;
TempProxy : TIdConnectThroughHttpProxy;
......
TempIO :=TIdIOHandlerStack.Create;
TempProxy :=TIdConnectThroughHttpProxy.Create;
TempProxy.Host :=Proxy_host;
TempIO.TransparentProxy:=TempProxy;
IdFTP1.IOHandler :=TempIO;
IdFTP1.Connect;
Update 2
A point of clarity: the HTTP request that is successfully reaching the web server through the proxy server goes to a different web address than the FTP request. In other words, they both go through the same proxy server, but the destination addresses are different. Just in case this is of use.
I have now tried using Fiddler to find the problem, not sure if this is a great idea? My understanding is is that Fiddler acts as a proxy server, so I thought I would see if I encountered the same problem. Sure enough, can't connect.
To be clear about my steps:
Run Fiddler, and check the box that says 'Capture FTP requests'.
Update my IdHTTP component:
IdHTTP1.ProxyParams.ProxyServer:='127.0.0.1';
IdHTTP1.ProxyParams.ProxyPort :=Fiddler port;
Update my IdFTP component:
IdFTP1.ProxySettings.Host:='127.0.0.1';
IdFTP1.ProxySettings.Port:=Fiddler port;
So now I have removed the client setup completely, I am mirroring the problem from my local machine using Fiddler as far as I can tell. If I don't use Fiddler, everything works great. If I use Fiddler as described above, then the HTTP request works correctly, but the FTP request can't connect.
Any ideas as to what I can do to try and solve this? I'm sure it is something really stupid that I'm doing wrong.
IdFTP1.ProxySettings.ProxyType:=fpcmNone
This tells TIdFTP not to communicate with an FTP-aware proxy. If you want to use the TIdFTP.ProxySettings properties, you need to set the ProxyType so TIdFTP.Connect() will connect to the ProxySettings.Host and TIdFTP.Login() will know what kind of commands it needs to send to login to the proxy and request a connection to the next host.
Note that TIdFTP.ProxySettings only works with FTP proxies. If you need to connect to a different type of proxy, before you call TIdFTP.Connect() you will have to assign a TIdIOHandler-derived component to the TIdFTP.IOHandler property, and then assign a TIdCustomTransparentProxy-derived component to the TIdIOHandler.TransparentProxy property. To connect to an HTTP proxy (which it sounds like you need, since that is what TIdHTTP.ProxyParams works with), use TIdConnectThroughHttpProxy. To connect to a SOCKS proxy, use TIdSocksInfo.

Is it normal to be able to see https headers?

I've written a small application using delphi to update my twitter status.
I use Indy 10 and OpenSSL and everything works fine, which means that i can both authenticate my app and update my status.
The thing is that if i use a program like "http analyzer" i can see the request's headers and so i can see sensitive information like the consumer_key.
Is that normal or is it a sign that i have not set properly the iohandler (TIdSSLIOHandlerSocketOpenSSL)?
mSslIoHandler.SSLOptions.Method := sslvSSLv3;
mSslIoHandler.SSLOptions.Mode := sslmBoth;
mSslIoHandler.SSLOptions.VerifyMode := [];
mSslIoHandler.SSLOptions.VerifyDepth := 0;
By providing their own SSL certificates, HTTP analyzers are able to monitor the HTTP traffic as if it was unencrypted. I guess you have to set the analyzer IP address and port as proxy only, and leave the destination server address and port unchanged in the client. Then the analyzer will be able to decrypt your client data with its own key, and forwards it to the destination server. (This is the same way a 'man in the middle'-attack would work)
So yes, it is normall with this type of HTTP analyzers (such as Fiddler)

Indy TCP Client/Server with the client acting as a server

How can Indy's TIdTCPClient and TIdTCPServer be used in the following scenario:
Client ---------- initate connection -----------> Server
...
Client <---------------command------------------- Server
Client ----------------response-----------------> Server
...
Client <---------------command------------------- Server
Client ----------------response-----------------> Server
The client initiates the connection, but acts as a "server" (waiting for commands and executing them).
The OnExecute approach of TIdTCPServer does not work well in this case (at least I am not getting it to work well). How could I do this?
I hope the question is clear enough.
There is nothing preventing you from doing this with Indy's TIdTCPServer component.
A TIdTCPServer only sets up the connection. You'll need to implement the rest. So the sequence of the actual sending and receiving can be whatever you want.
Put this code in your TIdTCPServer component's OnExecute event:
var
sName: String;
begin
// Send command to client immediately after connection
AContext.Connection.Socket.WriteLn('What is your name?');
// Receive response from client
sName := AContext.Connection.Socket.ReadLn;
// Send a response to the client
AContext.Connection.Socket.WriteLn('Hello, ' + sName + '.');
AContext.Connection.Socket.WriteLn('Would you like to play a game?');
// We're done with our session
AContext.Connection.Disconnect;
end;
Here's how you can setup the TIdTCPServer really simply:
IdTCPServer1.Bindings.Clear;
IdTCPServer1.Bindings.Add.SetBinding('127.0.0.1', 8080);
IdTCPServer1.Active := True;
This tells the server to listen on the loopback address only, at port 8080. This prevents anyone outside of your computer from connecting to it.
Then, to connect your client, you can go to a Windows command prompt and type the following:
telnet 127.0.0.1 8080
Here's the output:
What is your name?
Marcus
Hello, Marcus.
Would you like to play a game?
Connection to host lost.
Don't have telnet? Here's how to install telnet client on Vista and 7.
Or with a TIdTCP Client, you can do this:
var
sPrompt: String;
sResponse: String;
begin
// Set port to connect to
IdTCPClient1.Port := 8080;
// Set host to connect to
IdTCPClient1.Host := '127.0.0.1';
// Now actually connect
IdTCPClient1.Connect;
// Read the prompt text from the server
sPrompt := IdTCPClient1.Socket.ReadLn;
// Show it to the user and ask the user to respond
sResponse := InputBox('Prompt', sPrompt, '');
// Send user's response back to server
IdTCPClient1.Socket.WriteLn(sResponse);
// Show the user the server's final message
ShowMessage(IdTCPClient1.Socket.AllData);
end;
An important thing to note here is that the ReadLn statements wait until there is data. That's the magic behind it all.
If your commands are textual in nature, then have a look at the TIdCmdTCPClient component, it is specifically designed for situations when the server is sending commands instead of the client. The server can use TIdContext.Connection.IOHandler.WriteLn() or TIdContext.Connection.IOHandler.SendCmd() to send the commands.
When the client connects to the server, the server has an OnConnect event with an AContext: TIdContext parameter.
A property of this is AContext.Connection, which you can store outside of that event (say, in an Array). If you pair it with the IP or better yet a generated Session ID, then reference that Connection by that criteria, you can then have the server send adhoc commands or messages to the client.
Hope this helps!
normally the client and the server side have a thread that is reading incoming telegrams, and sending pending telegrams...but this kind of protocols (send/receive, when and what) depend of the application.
A very good starting point how the client side can be implemented using a thread, listening for messages from the server, is the Indy Telnet client component (TIdTelnet in the Protocols folder).
The Indy telnet client connects to the telnet server and uses only one socket to write and read data. Reading happens in a listener thread.
This design can easily be adapted to build distributed messaging software like chat etc., and also shows how easy the protocol can be decoupled from the network layer using blocking sockets.
With Indy this is not possible by design:
Indy supports only Client-initiated communication, what means the server can only send a response to requests by the client.
The easiest way (but not the smartest) to get what you want is to use a pull-process. Controlled by a timer the clients ask the server if there is a new command. Of course this will cause a lot of traffic-overhead and depending on your pull-intervall there is a delay.
Alternatively you could use another library like ICS (http://www.overbyte.be/eng/products/ics.html)

Delphi 2009: How to communicate between Windows service & desktop application under Vista?

How can a desktop application communicate with a Windows service under Vista/Windows2008/Windows7? The application needs to send small strings to the service and receive string responses back. Both are written in Delphi 2009. (Please provide sample code also)
The way to go is named pipes, you'll probably have to take a look at the communication across different Integrity levels.
This article explores how to do this in vista. Although it's written in c++ it's just basic Windows API calls, so it should translate fast enough to Delphi.
If you want to search for more on this subject, this communication is called Inter Process Communication, but a better search term is IPC.
Using Indy you can relatively easy create a TCP connection between your apps. Especially if you only need to send string messages. For the client (in your case the desktop application) it's basically
var
Client : TIdTCPClient;
...
Client.Host := 'localhost';
Client.Port := AnyFreePortNumber;
Client.Connect;
Client.IOHandler.Writeln (SomeString);
Response := Client.Readln;
...
Client.Disconnect;
For the server (would be the service in your case)
var
Server : TIdTCPServer;
Binding : TIdSocketHandle;
...
Server.DefaultPort := SameFreePortNumberAsInClient;
Binding := Server.Bindings.Add;
Binding.IP := '127.0.0.1';
Binding.Port := Server.DefaultPort;
Server.OnConnect := HandleConnection;
Server.OnDisconnect := HandleDisconnection;
Server.OnExecute := HandleCommunication;
Server.Active := True;
Just implement the HandleCommunication method. It is called whenever the client decides to send something. Example:
procedure MyClass.HandleCommunication (AContext : TIdContext);
var
Request : String;
begin
Request := AContext.Connection.IOHandler.Readln;
if (Request = Command1) then
HandleCommand1
else if (Request = Command2) then
HandleCommand2
...
end;
IIRC a service is only allowed to have a graphical user interface OR have network access, so this might be a problem if your service needs a GUI (which you should avoid anyway, see this question). I don't know how this is handled in Windwos Vista and later though.
Have a look at the answers in Exchange Data between two apps across PC on LAN which is pretty much the same question nowadays. Local comms via TCP is standard. As I said in my response there, solutions that use "Remote Procedure Call" type interfaces work well. I use RemObjects SDK for this sort of thing, and it makes it easy to expand to control across the network if you wish to later.
Both of these allow you to create a connection that for most of your code is "transparent", and you just call an interface which sends the data over the wire and gets results back. You can then program how you usually do, and forget the details of sockets etc.
You have to change the service user from localsystem to networkservice and then the service can use TCPIP fine. I have several services which use TCPIP for an external control hook. Just make sure your service port is configurable so you can handle any collisions.
A few of my control interfaces are based on XML pages served from an internal HTTP server. This allows me to remotely check on status of the service using any web browser which can reach the port on that machine. The advantage of using HTTP over other methods is that it works well when you need to work over existing network hardware.
If your ONLY going to be communicating locally, then named pipes, mail slots or a memory mapped file might be the best method.
I haven't tried it, but I think you could use named pipes.
I use in my service applications a component set, freeware with sourcecode called Simple IPC.
Search torry.net. It has worked very well in all of my service apps when communicating with a desktop app.
John

Resources