70: Design Patterns: Proxy.

The proxy structural pattern introduces another object that your code uses instead of the actual object. This might seem pointless but there are some good reasons why you might consider this. Most design pattern references list four reasons why you might want to use a proxy. I explain three of them and then put the fourth in a separate explanation because I think the fourth reason can lead to a security vulnerability if implemented wrong. The real object might be big or slow to create. Maybe this object is only used rarely in your application. Or maybe it’s always used but just not right away. If you use a proxy, then you can let the proxy create the object when it needs to. The real object might not exist on your local computer at all. Or if it does exist on your local computer, it might live in another process that’s isolated from your application. A proxy allows you to work with the object as if it’s readily available nearby. You need to do some extra work when accessing the object such as coordinating access from multiple users. Most of the documentation that describes the proxy pattern actually mentions another common scenario to control access to an object. Maybe you want to verify if the calling code is actually allowed to use the object. Any object responsible for security needs to be protected and reliable. Now typically, a proxy runs in an application right along with the other code. If you put the proxy on some user’s computer, then it’s under that user’s full control. Now granted, most users won’t know what to do with this or how to exploit the vulnerability. But it only takes one user to figure out that all they need to do is change a little bit of code to bypass the authorization and always make the call to the real object to perform the work. If you’re going to use a proxy to control access, then you either need to duplicate that access check in the real object or make sure the proxy can’t be bypassed. Implementing a proxy is fairly straightforward. Since it needs to be used in place of the real object, it needs to have the same interface as the real object. Ideally, the code using a proxy shouldn’t know that it’s using a proxy at all. It should think that it has direct access. You can use a factory to create either the real object or a proxy. Listen to the full episode or you can read the full transcript below. Transcript The basic description says that this pattern provides access to an object through another surrogate or placeholder object. Why would you want to purposefully introduce a middleman? If you’re buying or selling an item, your first inclination might be to avoid another person and go straight to the seller or buyer. This might work out well for you and you can get a better deal. But is that always the case? A good agent should help you more than what it costs to retain the agent. Or maybe you have something to sell and there’s a local store willing to buy the item from you today at a lower cost. You can sell the item to the store or wait until you find a direct buyer and hope to get a better price. What I’m trying to say is that in real life, going through another person or company instead of directly to your intended client or customer is sometimes very useful. And there are valid reasons why you might want to do the same thing in software. Here are three common reasons that the proxy pattern is used: ◦ 1. The real object might be big or slow to create. Maybe this object is only used rarely in your application. Or maybe it’s always used but just not right away. You can either make the user wait, add extra complexity to your program to skip this object and come back to it later, or use a proxy. If you use a proxy, then you can let the proxy create the object when it needs to. ◦ 2. The real object might not exist on your local computer at all. Or if it does exist on your local computer, it might live in ano