Do not use IE browser settings when using a proxy with Indy - delphi

At one of our customer sites, we have a Delphi 2007 application that makes a number of HTTPS requests using indy components. All requests are made using the proxy settings the client provides.
For this to work, in IE we have to put the URL's in the trusted zones section. After a month due to security settings the trusted zones are cleared. This means we have to re-add the URLs again to make our application work.
Is there a way of bypassing IE settings or using a client side HTTP stack so we do not go through the browser to make https requests?
JD

Indy is the client-side HTTP stack. It doesn't use Internet Explorer's proxy settings. It uses whatever proxy settings you've set in the TIdHTTP component's proxy-related properties. If you don't want to use those settings, then don't set them.
Furthermore, I'm pretty sure the "trusted zone" has nothing to do with this. It controls what Internet Explorer allows Web pages to do, such as run scripts and load ActiveX controls. Indy never loads, displays, or executes anything. All it does is download. Internet Explorer's settings should have no bearing on your program's ability to connect to whatever sites you wish.

IE proxy settings are handled by the Internet options -> Connection -> Lan settings -> Proxy server configuration. Here you can tell which addresses should bypass a proxy server, it's not the security tab controlling that, it controls what a site is allowed to do within IE, and zones are used by IE only (and applications using the Web Browser control). Anyway, Indy does not use them automatically, you have to set a proxy explicitly. Do you use the web browser control?

Related

How can I create an iOS web browser that proxies all traffic through a proxy server?

I'm looking to create an iOS app that implements a standard Safari-like web browser which proxies all of its traffic through a proxy server. Specifically, it must use its own a proxy configuration so that only its traffic is directed through the proxy, as opposed to using iOS's system settings.
I have some flexibility with what kind of proxy is used. I'd prefer a Socks5 proxy, but an HTTP / HTTPS proxy is okay too. Either way, it must support authentication.
I'd strongly prefer to use SFSafariViewController, as I'd like this web browser to be as close to the experience of using Safari as possible, but I understand that SFSafariViewController is limited and that may not be possible. Failing that, I'd hope to use WKWebView, but if that's not possible either, I can reluctantly fall back on UIWebView.
How would one go about accomplishing this?
edit: I should add that I'm not planning on releasing this app on the app store, so I'm open to methods that normally wouldn't fly there, like undocumented APIs and swizzling. All else being equal though I'd prefer to not utilize methods like that.
You can implement a local web server, hosted at localhost:<some_weird_port_number>, and make your WKWebView load only local addresses from that server. Your server will load what you want and how you want, and then will give it as a response to a web view.

Sending Commands to a Remote Printer

I'm working on a web project in which I need to be able to communicate directly with my customer's printer. The customer uses my application through a browser, and would like to be able to click a button to print tickets uninterrupted, meaning there is no printer dialog popup from the browser. This requirement eliminates many traditional ways of sending information to the customer's printer, and because I want a solution that will work on any browser, solutions that use VBSCRIPT or other browser-dependent solutions will not work.
My initial solution for this problem was to create a Java applet that was loaded into the page dynamically when a "Print" button was clicked. However, browsers like Chrome and soon Firefox are removing support for NPAPI, which breaks my Java plugin.
The current solution I'm working on is to create a service in C# that the user installs locally on their machine, and then when the customer clicks the "Print" button, my server communicates with that service directly. This way I can bypass the browser restrictions, and the service running on the customer's machine will have full access to communicate with the target printer. The downside to this approach is that the user now has to install an additional bit of software on their machine, and for each machine they wish to access my application on and print from, that machine needs to have proper port-forwarding and firewall settings configured. I can make this work for my current customer, but with future customers it becomes a hassle. Furthermore, my new approach currently only supports Windows machines, and if future customers are using OS X or Linux, I will need to port the service.
Has anyone faced this problem before, or are there any ideas out there for how to communicate with a client's printer that is browser-independent?
There's no possible solution to this that both supports Chrome and doesn't require something to be installed on the machine; you can't run arbitrary code that interfaces with the OS from within Chrome. And the only way to interact with that other code besides a local web server would be Native Messaging in an extension, but that doesn't fulfill your cross-browser requirement.
you can't communication directly because of security. i also develop 1 application in c# for remotely printing.
there is one way if your client have remote printer then you can do this task easily make small app on server and integrate with all remote printer and you can execute printer command from server and print will comes from client printer

How can I change the ssl port number for my asp.net mvc web application inside Visual Studio

I have two web applications that are both using the same ssl port number https://localhost:44300/; which doesn't allow me to run both of them at once.
How can I change the port number for one of the web applications to use port number 44301?
I right clicked on the project, then I clicked on the Web tab but this will only allow me to change the http port and not the https port.
To complement Dandy's answer comment, this is a picture of the section where you can make changes relating to the server/port you want to use for your app. You can also select if you want to use a local IIS server or a remote host.

Security warning to save cookie when using Indy TIdHTTP

I am developing a Delphi XE4 application that crawls a web site for certain information. It reads web pages with TIdHTTP and then parses with MSHTML using the IHtmlDocument2 interface.
The code works, but on one web site (www.orlytaitzesq.com), I get a Microsoft security dialog popup:
"Windows Security Warning
To allow this website to provide information personalized for you, will you allow it to put a small file (called a cookie) on your computer?"
It doesn't matter how I set "Allow Cookies" on the TIdHTTP component or whether I include a cookie handler. This warning just pops up randomly (following an Application.ProcessMessages) and my program stops until I respond to the dialog. This happens over and over again at random intervals. I have the Windows 7 Internet Options set to allow all cookies from the Internet Zone. I have IE 11. The web site I'm having the problem with is crawling with advertising.
I really don't understand what's happening, nor how to stop it.

Should I port my WebBroker projects to Indy

Long ago I started some "web applications" using Delphi 2007 and WebBroker (TWebModule). At the time I assumed you needed a webserver such as Apache or Microsoft IIS in order to create any sort of website. Additionally I don't use most of the Apache features (except for Virtual Server so I can have multiple domains on a single ip address and SSL). So to me Apache is just an extra layer and makes makes debugging difficult.
Now enter Indy (TIdHTTPServer). If I understand correctly, Indy IS a webserver. So by using Indy I am no longer bound to use Apache or some other webserver. Is this correct?
Will I have any issues supporting the Virtual Servers in an Indy environment? And what about SSL. I have searched the literature and from what I can see it fully supports SSL certificates.
I am now in the process of porting some of my application from WebBroker to Indy. This mostly entails replacing within my code references of Request: TWebRequest with ARequestInfo: TIdHTTPRequestInfo and references to Response: TWebResponse with AResponseInfo: TIdHTTPResponseInfo.
Is there anyway to use the TWebModule architecture within Indy so that I don't need to do all of this rewriting?
Lastly is there anything else I need to be concerned with? My goal is to take Apache out of the loop.
Yes, you can use Indy's TidHTTPServer as a webserver, but it's much lower-level than IIS or Apache. There is no concept of virtual servers - this you would have to implement yourself.
Indy does support SSL as well via the OpenSSL dll's.
I imagine the biggest concerns you will have will be security related...there are millions and millions of sites running Apache or IIS and there are a ton of people devoted to finding flaws in those platforms, with a bunch of people fixing some of those flaws as they come up. Not so with Indy... there's one or two guys that respond on newsgroups to bugs that you discover. (One guy in particular, who will probably respond to your question here as well.)
Now, I use Indy HTTP server (along with SecureBlackBox SSL support) and I find it to be great for my purposes.
Indy HTTP server calls the WinSock API, and is able to implement:
A full HTTP/1.1 server;
A full HTTPS server (using either OpenSSL libraries or other third parties, like SecureBlackBox).
AFAIK you can use Indy to publish web modules.
See http://www.2p.cz/files/2p.cz/downloads/howto/indy_soap_web_services_in_delphi.pdf
You can also use other servers, for instance directly the kernel-mode http.sys server, which is used by ISS and .Net WCF for instance, and known to be very stable and efficient (it bypasses the WinSock APIs). Of course, it will serve HTTPS conent, if needed. It is available in standard since Windows XP SP2, and therefore in Vista and Seven. Using this component will let Microsoft will do all the debugging work for you, and it will be updated with the host OS. I use it for instance in our Client-Server ORM, or directly to replace a deprecated DCOM connection, with very good speed and stability on customer side.
Regarding virtual servers - the HTTP 1.1 spec requires clients to send a Host request header so virtual servers know which domain is being used specifically to handle the case when multiple domains have the same IP. TIdHTTPRequestInfo has a Host property for that value. In fact, TIdHTTPServer internally validates to makes sure that an HTTP 1.1 request has the Host header before firing any of its OnCommand... events.

Resources