It's very convenient for users to be able to communicate with web applications (or businesses) via email, but it's not always easy for the employees of the company to respond. Some of the email requests could be complex, and others could be simple but occur very frequently. So it's a real advantage when we can write scripts to respond to user emails for us.

The tutorial sets up a basic structure for you to work from including places for the addresses and extra headers for the response. You can also download the code to have it to follow along with (or play around with yourself).

Developers place too much trust in everything, they assume that certain data cannot be faked and therefore these pieces of data can be used as a Trojan horse. Lets take the REMOTE IP of a user, it seems a trusted source because of the TCP/IP connection between the user and the server.

He points out the difference between HTTP_X_FORWARDED_FOR and REMOTE_ADDR and how, despite them being the same almost all of the time, shouldn't be trusted since they could be spoofed. He even includes an example script showing how it could be done (and how a bit of Javascript can even be inserted).

The advantage of this is primarily security, however you often can send larger amounts of data with the POST method as well (but that is dependent on your server configuration rather it be Apache/PHP, Microsoft/IIS, or Java/J2EE, etc). The primary advantage of POST is again, the security of the communication, because often log files on the web server will log the AJAX GET request data because that data is part of a URL in the request. This does not occur with the AJAX POST request.

They start with a simple example of the POST request type, pulling data from a form (address/city/state/etc) and pushing it to the backend script. They follow this by picking it apart, explaining each of the sections of code for a better understanding.

A few weeks ago, I posted a regular expression pattern < href="http://tiffanybbrown.com/2006/11/09/a-pattern-for-matching-e-mail-addresses/">for matching e-mail addresses. Below is a more refined version:

Not only does it match the traditional email address formats, but it also will match addresses with periods in the name, British domains, and new TLDs like '.travel' or '.museum'.

They're also offering the source for the application so you can get behind the scenes and see how it works. It definitely does a good job at making things more difficult, but I'm not sure how useful it really is in practice. If you're just using it to drop into a one-time kind of location, it would work, but the results this thing spits out would be a nightmare to maintain (especially the HTML).

One good thing, though, is that too the user, it all looks seamless. There's no funny characters or things they'd have to change in their browser to get it to work.

I had nothing on Jeremy, all I knew was that he was speaking at OSCON and he worked at Yahoo. As it turns out, it was a very interesting interview. Not for the normal reasons though. If you want more, you'll have to come inside and read the interview.

Well, I'll cheat a bit and tell you some of the topics they talked about such as:

• Jeremey's experience and background
• his experience at Yahoo!
• some of the work he's done there (including the Address Book application)
• Yahoo!'s move to PHP 5
• everyone's favorite topic - "disaster recovery"

Blocking certain IP addresses from your site is actually much easier than you might think.

In fact, it is only a seven-line code inserted at the top of your page!

The code basically just looks in an array of IP values and checks to see if the remote user's matches any of them. If it does, it echos out an error and stops the page execution. Obviously, this is just a basic example, and could be enhanced with a databse table that would be easier to manage than just the static array.]]> Mon, 06 Mar 2006 07:18:29 -0600 http://www.phpdeveloper.org/news/4448 http://www.phpdeveloper.org/news/4448 PHP Magazine has posted this new article from Lukas Smith today with a "State of the PEAR Address", an overview of where PEAR stands in the PHP community today.

For those of you who have been living under a rock the last few years, you may have managed to evade PEAR. However, avid readers of the International PHP Magazine will know PEAR quite well, so here is a quick run down.

He goes through a look at what PEAR is, the debates over its structure, monitoring for "high-quality non-redundant code", what checks and balances are in place, the myth of bloated PEAR code, how you can contribute, and a call to action for all developers out there to get involved. There's a lot more in there than that, but you'll have to check out the whole article for that...]]> Tue, 06 Dec 2005 07:49:25 -0600