14.2. A New Development

 <  Day Day Up  >  

Sam called me up in an excited voice. "I've got great news."

"What? The coffee shop is having a special on double lattes?" I asked.

"Are they? I'll have to head down there," he replied. "My news is that I've hooked up with some web sites that catalog CDs. When someone gets to a CD that I have in stock, the web site posts a message telling the user that they can rent the CD at my store. I give them a cut of the rental in return."

"That sounds interesting. Are you going into the mail order rental business?" I asked.

"Not yet. But I'm getting ready," he answered . "I need you to work out the details with the web guys."

14.2.1. The Interface Contract

I called up the maintainers for one of the CD catalog sites. We discussed the interface operation and how we were going to communicate with each other. We created an interface with a single method: show_availability_of_CD_release(UPCCode upc_code) . We also agreed on using Web Services as the communication protocol.

The show_availability_of_CD_release( ) method in StoreCollection is going to be exposed to the outside world. That calls for another interface, ExternalServiceProvider , to keep external services separate from internal services. The module in Sam's system that receives the request is:

 interface ExternalServicesProvider         StoreExternalDTO[] show_availability_of_CD_release(UPCCode upc_code) 

StoreExternalDTO parallels the Store class. We make up a separate class so that we are free to alter the internal class, if necessary:

 class StoreExternalDTO         CommonString name         Address address         PhoneNumber phone_number 

When the web service is invoked on Sam's system, the service calls the method in this interface to obtain the result to return to the other site.

14.2.2. Keep the Cold Air Out

Any interface that permits access by system outsiders needs to be designed carefully . All input should be validated and logged. Even if there is no value-level validation, such as a low and high range, almost any data should be subject to some form of checking.

For example, if the data is coming from a web page, or is on a web service request, the input should be converted to SymbolFreeStrings . The conversion would eliminate extraneous characters , such as ; and ? . Hackers commonly break into web sites by entering strings into form fields that contain characters that handling programs on the server might interpret as commands. [*]

[*] Languages such as Ruby and PERL have the concept of "tainted" variables. Variables that are tainted have not yet been checked for validity. Once they have, they can be "untainted."

Logging access from outsiders can help pinpoint problems that they are having in communicating with your system. Logs can also help determine what methods hackers might be using to attack your system. For example, the ExternalServicesProvider implementation will be monitored similar to the log of Zip Code lookups in Chapter 11 to ensure that it is accessed correctly by only authorized users ("If You Forget Security, You're Not Secure").

DON'T LET THE COLD AIR IN

With interfaces exposed to the outside world, ensure that input validation and logging occurs .


Outside interfaces are particularly more vulnerable than internal interfaces. So this guideline emphasizes and extends the "Validate, Validate, Validate" guideline.

 <  Day Day Up  >  


Prefactoring
Prefactoring: Extreme Abstraction, Extreme Separation, Extreme Readability
ISBN: 0596008740
EAN: 2147483647
Year: 2005
Pages: 175
Authors: Ken Pugh

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net