On his site Nikola Posa has a tutorial showing how to lazy load services with Zend Manager, a component of the Zend Framework. In this case, the "services" being loaded are in a dependency injection container.

Any more complex application includes a big dependency injection tree of services, some of which can have a more complicated creation logic. If the service is injected as a dependency, but not necessarily used at every execution, you may want to lazily initialize that service until it is really needed.

In those situations, you may be tempted to inject the entire Dependency Injection Container instead, and lazy-load that resource-hungry service. I find that to be an anti-pattern, and I explained my views in a blog post written some time ago.

He offers a better solution in the form of the proxy design pattern, making it possible to decouple the services from the dependency injection container. He provides examples of using this pattern along with the Zend Service Manager functionality to create the factories and the services configuration.

Sergey Zhuk has posted the third part of his series covering the use of ReactPHP to scrape content from another source on the web. In this third part of the series he improves on his scripts from before (scraping from the IMDB site) to add in a proxy server.

n the previous article, we have created a scraper to parse movies data from used a simple in-memory queue to avoid sending hundreds or thousands of concurrent requests and thus to avoid being blocked. But what if you are already blocked? The site that you are scraping has already added your IP to its blacklist and you don’t know whether it is a temporal block or a permanent one.

Such issued can be resolved with a proxy server. Using proxies and rotating IP addresses can prevent you from being detected as a scraper.

He then shows how to use the clue/reactphp-buzz package to write an asynchronous HTTP request to google.com making use of promises rather than normal synchronous request handling. He then installs the clue/reactphp-socks package to make the connection to the proxy server(s) and modifies the Buzz client to use that as a connection. After finding a proxy server to use, he updates the scraper code created previously with the new Buzz+Socks combination and shows it in action scraping data. The post finishes with a look at adding some error handling and how to handle when the proxy requests authentication before use.

On the Laravel News site there's a new post about a feature introduced in version 5.5 of the popular PHP framework: a proxy that's included by default as a part of the TrustedProxy feature.

Laravel v5.5 was released just a week ago at Laracon EU. You may have noticed that the v5.5 composer.json file requires the similar functionality Symfony has).

David Lundgren has a post to his site talking about the allure of static proxies in your development and some of his own experiences using them in his own code (and in using Laravel).

Several weeks ago I started playing with Laravel. Primarily because several colleagues are using it, and have suggested that I take a look at it. During my time reviewing how to build a view template I came across references to Html, Form, View and other static calls. Initially I was not impressed due to the use of so many static calls. I have come to an understanding about how static calls in certain circumstances can actually enhance code readability.

He talks about how static calls have been considered an anti-pattern for a long time due to difficulty testing and tight coupling issues. That being said, he did start to see the value in using them in certain situations, how his use relates to the proxy design pattern and some of his own conclusions about using static calls.

Recently a major security vulnerability was announced centering around the the HTTP "Proxy" header and how incorrect handling could result in major issues with external requests. In the PHP ecosystem, a major HTTP library - Guzzle - was vulnerable (along with any application using it). However, according to Michael Dowling, a lead developer on the project, a new release has already been made to correct the problem.

httpoxy is a set of vulnerabilities that affect application code running in CGI, or CGI-like environments. It comes down to a simple namespace conflict [between the "Proxy" and "HTTP_Proxy" headers]. This leads to a remotely exploitable vulnerability. If you’re running PHP or CGI, you should block the Proxy header now. Here’s how.

The main HTTPoxy site as more information about how you can test to see if your application is vulnerable and what software/server configurations are typically vulnerable. There's also more language-specific information on the page as well as some immediate mitigations for various web server types.

The ProDevTips.com site has a tutorial posted showing you how to proxy requests with PHP on Ubuntu using Apache 2.4 and PHP version 5.4 or later.

I’ve just had to evade a Russian block of one of my employer’s sites, let’s call it CasinoX. Presumably they had blocked both www.casinox.com and www.casinox.com’s IP address (which is a Cloud Flare IP btw).

Simply pointing ru.casinox.com to the real IP address of www.casinox.com’s server was a not a viable solution though as that would expose the real IP publicly which is a no-go in the online casino business as it is basically an invitation to be DDoS’ed.

The solution they came up with was to set up a server that operates as a proxy and sends all traffic to the actual web server, save the assets (images, Javascript files, etc). They include the changes you'll need to the .htaccess configuration on the proxy server to forward the requests. Then they show the updated version of your virtual hosts configuration to match these changes. From there the rest of the handling lives in PHP. They include the code for the index.php proxy handling, a Proxy class that makes curl requests to the actual web server and an ip_in_range function to get the actual IP of the user/client making the request.

The "Snack Overflow" blog (from tech.graze.com) has a recent post sharing some suggestions to help unit test static calls without having to "refactor the world" away from them.

Imagine you have a situation [using a static method call] in some legacy code. Currently we can't unit test this as we can't mock out the doSomethingElse() call. So what do we do? Well we have two options really [...] neither of which is very appealing. [...] There is, however, a third option that gains us the ability to unit test Foo without having to touch Bar at all.

This option involves creating a "proxy" object of the "Bar" class that's non-static and only returns the result of the previous class' static method. You can then correctly mock that class and return the result in a more self-contained way. He lists a few caveats with this method including the fact that it could lead to a lot of proxy objects if there are a lot of static methods to replicate.

In a recent tutorial to on the SitePoint PHP blog, Alexander Cogneau shows you how to create a personal Packagist (the repository for Composer packages) using the Toran proxy.

Most of you reading this already know Composer. For those who don’t, you can read a previous article of mine before continuing. We can all agree that Composer has brought many good things into the PHP world. If one dares however to look for drawbacks, or better put, not included features, he could state that it is not possible to work with private repositories. That argument won’t hold anymore, since there is Toran Proxy.

He calls this the "end of the Satis era", replacing the Packagist clone that mirrors the packages locally rather than pulling them right from GitHub. Using the Toran proxy, he walks you through the setup of the proxy and using the wizard to complete the configuration. There's a personal use license for Toran that allows for one developer but after that you'd need to upgrade to the yearly/per developer pricing structure.

On thePHP.cc blog today there's another post looking at an improvement in the latest release of the popular PHP unit testing tool, PHPUnit 4.0.0. In the post Sebastian Bergmann looks at test proxies.

One of the highlights of PHPUnit 4.0, which was released last week, is improved support for integration testing through so-called test proxies. [...] PHPUnit has had built-in support for stubs and mocks for quite some time. These stubs and mocks can be used in every context where an object of the original class is expected. As it should be, the code of the original class is not executed when a method is called on the stub or mock. [...] PHPUnit 4.0 introduces the concept of test proxies [...] to have an object that provides the same API for expectations as a mock object while at the same time proxying method calls to the original class.

He includes some code examples to help illustrate. He creates a "SimpleWorkflow" class and shows how to test the execution of its "doWork" function to return the correct kind of "Result".

In this new post to his site Chris Hartjes shares a tool he's found to help with automated front-end testing for web applications - BrowserMobProxy

At work I have been involved with an effort to put some automated front-end testing in place. The combination of Behat, Mink running tests using PhantomJS is a good one for this. Open source, easy to configure, handles JavaScript-heavy pages reasonably well. There was just one wrinkle in our plans: our use of local host files. [...] So clearly what was needed [to solve a hosts file switching issue] was a proxy. After doing a little bit of digging around I found a solution: BrowserMobProxy.

He briefly introduces the tool and helps you get it installed (as well as the library you'll need to interface with the proxy). His library hooks into a running PhantomJS instance and the BrowserMobProxy, generates the right hosts file (not included) and continues on with the tests.