I am looking for a method to intercept http post requests with delphi without hooking any browser functions.Is that possible? How??
You could use something like WinPCap to grab intercept all packets looking specifically for packets on port 80 using the http protocol with a POST. There is a Delphi wrapper available which might be of some help. This is the same engine that is used by WireShark which would be useful by itself if your just having to do this manually or to debug an existing protocol.
In stead of doing this in Delphi, you might want to consider good and scripteable free solutions like Http Fiddler?
Edit:
If you want to write a proper and fully fledged proxy from scratch, that works well with most of the idiosyncrasies of possible http clients and servers, be prepared for at least a couple of man-months work.
If you are willing to use at least some base libaries, then look into this question.
--jeroen
You'd have to create an application that acted like a local Proxy Server that caught all requests made and then forwarded them out to the appropriate server.
I'm not sure which version of Delphi you're using, but you might want to check out this sample Proxy Server in C# and see if you can port the basics to suit your needs.
Related
I have implemented a custom email server and web client. The server is just a REST API (similar to google's gmail API) that uses a 3rd party (sendgrid) for sending and receiving. The emails are stored in a database. The web client just talks to the REST client for sending and receiving.
The problem with this approach is it doesn't implement IMAP anywhere, which makes it impossible for standard clients (outlook, iphone, etc.) to connect to and use our email API. This limits customers to using only our client for email.
What I need is some sort of IMAP Server "facade" that will manage the connections to clients and make calls to my REST API for actually handling the requests (get email, send email, etc.).
How can an IMAP facade be implemented? Is there maybe a way to take an existing MailServer and gut it and point all it's "events" to making calls to my API?
tl:dr; write your gateway in Perl; use Net::IMAP::Server; override Net::IMAP::Server::Mailbox; and use one of the many Perl REST clients to talk to your server.
Your best bet for doing this quickly, while maintaining a reasonable amount of code security, is with Perl. You'll need two Perl modules. The first is Net::IMAP::Server, and here is the Github repository for that module. This is a standards-compliant RFC 3501 server that was purposely designed to have a configurable mail store. You will override the default Net::IMAP::Server::Mailbox implementation with your own code that talks to your custom email backend.
For your second module, choose your favorite Perl module(s) to use to speak to your REST server. Your choice depends on how much fine grained control you want to have over the construction and delivery of the REST messages.
Fortunately, here you have tons of choices. One possibility is Eixo::REST, which has a Github repository here. Eixo::REST seems to deal well with asynchronous vs. synchronous REST API calls, but it doesn't provide a lot of control over X509 key management. Depending on how googley your API is, there's also the REST::Google module. Interestingly, this family also has a REST::Google::Apps::EmailSettings module, specifically for setting Gmail-specific funkiness like labels and languages. Lastly, the REST::Consumer module seems to encapsulate a lot of https-specific things like timeout and authentication as parameters to Perl object instantiation.
If you use these existing frameworks, then about 90% of the necessary code should already be done for you.
Don't do this by hacking Dovecot or any other mail server written in C or C++. If you hack together a mail server quickly using a compiled language, your server will sooner or later experience all the joy of buffer overflows and stack smashing and everything else that the Internet does to fuck over mail servers. Get it working safely first, then optimize later.
(This is basically my comment again, but elaborated quite a bit more.)
Some IMAP servers, most notably Dovecot, are structured such that the file access is in a separate module with a defined interface. Dovecot isn't the only one, but it's by far the most popular and its backend interface is known to be appropriate, so I'd take that absent specific concerns.
There already exist non-file modules such as imapc, which proves that it can be done. When a client opens a mailbox backed by imapc, Dovecot parses IMAP commands, calls message access functions in imapc, imapc issues new IMAP commands, parses the server responses, returns C structs to Dovecot, Dovecot fashions new IMAP responses and returns them to the client.
I suggest that you take the dovecot source, look at src/lib-storage/inbox/index/imapc and the other backends in that directory, and implement one that speaks your REST API as a client.
Since you're familiar with .NET, I would suggest hacking either of the following implementations of IMAPv4 servers to your liking:
Lumisoft Mail Server - a very old project indeed (let's call it "mature", huh?). Don't be too turned off by the decade-old website and the lack of a github link - the source is provided under "other downloads".
McNNTP - also an older project and with a major focus on NNTP (as the name says) but very close to what you're trying to achieve in terms of the IMAP component. Take a look, you'll probably find this a good starting point.
Does Dart have any support for the FTP protocol. In particular code running on the server not the client.
thanks
Richard
https://api.dartlang.org/apidocs/channels/stable/dartdoc-viewer/dart:html.HttpRequest says
HttpRequest can be used to obtain data from HTTP and FTP protocols, and is useful for AJAX-style page updates.
I don't know if there is more necessary to get FTP support as you might want it.
Is it possible to convert Delphi SoapServer application to use TCP/IP?
From your comment to your question it sounds like you are looking to get rid of SOAP, and use something else to communicatie over a TCP/IP connection.
The question one could ask is why do you want to convert to non-SOAP comm over TCP/IP?
But the answer to whether it is possible is: of course this is possible, there are many application servers using TCP/IP for communication without using SOAP as their communication's protocol.
You will need some kind of protocol for communication between server and clients. You could roll your own, but doing what SOAP is doing for you now: receiving and responding to commands from clients (or method invocation) and marshalling data/objects between server and clients is not a trivial task.
So I'd suggest you have a look at other remoting libraries for client/server communication, such as:
Remobjects: http://www.remobjects.com/
kbmMW: http://components4developers.com/
As others have said, SOAP is just XML on http/https, and usually does already use TCP.
That said, you could simply treat it as raw socket data or http data. i.e. you could make a client that just uses http POST to send a string to the server. The string would contain an XML SOAP request, and would be treated by the server as if it were SOAP. Likewise, you could build the server in a non-SOAP fashion, just accepting XML and returning XML, and the client wouldn't know the difference.
You can use Fiddler2 to play with this. You can build requests and send them via HTTP Post. The server has no idea that you're not a SOAP client.
Chris
If you're talking about pre-Delphi
2009 DataSnap, meaning COM based
DataSnap, then you have to use a third
layer utility to do the communication.
That utility named sockets.exe is
included with Delphi, and is in the
same dir as Delphi (Program
Files\\\\bin
If it is Delphi 2009 or better, then
DataSnap has built-in TCP/IP
functionality. You use
TDSTCPServerTransporter component.
Update: Ups! for some reason I did read DataSnap SoapServer (wich neither exists, but I did think of Soap Connection).
A Soap Server Application needs the "server" part, meaning a web server. SOAP is an technologie that runs over HTTP protocol, so I don't think it could be "converted".
DataSnap could do the job, or Indy TIdTCPServer or some of the derived classes.
I need to write a Rails application (JRuby) that does asynchronous communication with another service in the background. There needs to be one connection per browser session. (It does not really need to be a open TCP connection but I need to free resources after the session ends.) The communication with the background service is not strict request - response. At any time there can be a message sent from the service to the rails app.
I also need to implement the protocol. How do I do this? Is there a asynchronous framework (e.g. like Twisted or Node.js) for Ruby on Rails? I just need some starting points.
I already wrote a quick implementation of the client side protocol in Python. In fact the complete protocol is made up by me (the server is written in JavaScript), so I could change the protocol completely. However, the asynchronous nature cannot be changed because of the nature of the problem.
Also I need XHR polling/WebSockets in order to push the async changes to the browser. Is there a gem/howto/tutorial for that? I can't just set the request to sleep (resources!).
In case you want to know more about the background:
The Rails application is a accessibility tool. The service with which it communicates is actually a Firefox Add-on that loads and renders webpages. The asynchronous nature comes from (i)frames, popup windows (window.open(), window.alert(), ...), dynamic changes to the DOM tree that have to be communicated to the Rails app, redirects (like after posing in a forum) etc. I need to use JRuby because I need to use the Jena (Java) framework for RDF processing.
Ruby On Rails is an asynchronous framework too. with a thin server. Node.js or Twisted are not a Asynchrone framework. There just Event framework.
In ruby the Event Framework is EventMachine and thin serveur use it. You can create some websocket with a rack::middleware and use it.
Have a look at Juggernaut 2, it does exactly this (and it also uses node). I am using it to push messages from my server to all connected clients and it works great. Implementation was a breeze (although the readme is a bit unclear on certain things), lemme know if you need any help with it.
I have some delphi code which, given a list of items, calculates the total price taking into account any special deals that might apply.
This code is non-trivial to rewrite in another language.
How should I set it up to communicate with a website running on the same server? The website will need to ask it for a price every time the user updates their shopping cart. It's possible that there will be multiple concurrent requests.
The delphi code needs to maintain an in-memory list of special deals, periodically refreshed from a database. So it cannot simply be executed every time or anything as simple as that.
I don't know what the website is written in, or even which http server it runs under, so I'm just looking for ideas or standard methods.
It sounds like the win32 app is already running as a Windows Service on the box. So, if you can't modify that service, you are going to have to deal with whatever way it wants to accept and respond to requests. This could be through sockets or some higher level communication protocol like web services.
You could do a couple of things. Write an assembly that knows how to communicate with the service and have your web site use that assembly. Or you could build a shim service that knows how to communicate with the legacy service, but exposes communication over higher level protocols such as web services. Either way will have the benefit of hiding the concurrency, threading and communications issue behind an easy to call interface, but the latter will make communicating with the service easier for everyone going forward.
If you can modify the delphi app to take an XML request and respond with an XML answer over a TCP socket (ideally using the HTTP protocol), you will be able to make it interoperate with most web server frameworks relatively easily. But the exact details of how to make that integration happen will depend on the language/framework it was written in.
If the web server is on windows you can compile your delphi app as a DLL that can return XML or HTML, taking parameters as part of the URL or a POST operation. Some details on making a Delphi DLL for web servers are here.
It doesn't matter what web server or OS the existing system is running under. What matters is what you want YOUR code to run under. If it is windows then the easiest solution would be to use WebBroker and write a custom ISAPI application, or use SOAP to expose web services. The first method could be used if you wanted to write a rest like API for instance, the second if your web application has the ability to consume web services.
Another option, if you are running both on the same box under IIS, is to create a COM/Automation object which you then invoke via server side scripting (ASP). If the application is an ASP.NET application, then I would use PRISM to port your code into an assembly.
I have done this with a quite complicated workers compensation calculator. I created a windows service using RemObjects Sdk. The calculations are exposed as a soap method so it can be accessed by nearly anything.
It's not necessary to use RemObjects in the service but it makes it much easier to do as it handles a lot of the underlying plumbing. The clients don't need RemObjects, they just need to be able to call soap methods. Nearly any programming langugae can do that.
You could also create an isapi dll for IIS that exposes a soap interface. This would be useful if other websites on different servers needed access to the methods. However I have handled this in my case by opening a port in the firewall to access my windows service.
There is a lot of examples on the web. A couple of places to start reading are About.Com and Dr Bob.
Torn this app into Windows Service. Write Web Service that will communicate with your windows service. You should spend some time designing your Web Service, because this Web Service is going to be your consistent interface, shielding old Delphi app. So in the future whenever you will want to write web app, mobile app, or whatever you will imagine, you will have one consistent interface – XML Web Service.
A popular way to integrate a web application with background services is a message broker.
The message flow would be:
the web application sends a "calculation request" message to a message destination on the message broker, which contains all needed parameters and also a correlation id to match the calculation request with the response from the Delphi service
one (or, in a high availability / load balanced environment more) Delphi services handle the messages: pull the next incoming message, process it by feeding the parameters to the calculation engine, and send a "calculation result message" back to the web server
the web server can either synchronously wait for the response (and discard responses which have no matching correlation ide) and build the result HTML document, or continue with other tasks and asynchronously receive the calculation result in a separate thread, for example in a Ajax based web application
See for an introduction this slideshow about the Dopplr image service:
http://de.slideshare.net/carsonified/dopplr-its-made-of-messages-matt-biddulph-presentation
If you can make it a service (but not a library), you have to do inter-process communication somehow - there are a few ways to do this on Windows:
Sockets directly which is hardest since you have to do marshalling/auth yourself
Shared Memory (yuck!)
RPC which works great but isn't trivial
DCOM which is easier but a pain to configure
WCF - but can you call it from your Windows Service written in Delphi?