This is usually done by adding the following to your “httpd.conf”…

AddType ‘application/x-httpd-php-source’ .phps

We use the cPanel web hosting control panel and to improve security cPanel recommend using suPHP, which allows PHP scripts to run as a user rather than “nobody”.

This means that adding the above line to “httpd.conf” does not work with suPHP.

So what can be done?

The official word is located in the suPHP FAQ, which says:

Does suPHP support code highlighting by using the “.phps” extension?

suPHP itself has no support for code highlighting. The main reason is that PHP-CGI does not support any input parameter to activate code highlighting. However there is a solution based on a small PHP script and some rewrite rules. You can find the discussion at http://forums.macosxhints.com/archive/index.php/t-23595.html.

So I decided to checkout the suggested link.

I noticed that even though the FAQ suggested using rewrite rules, the forum did not provide any kind of working solution.

Using the PHP code supplied, and a bit of rewrite ingenuity we can get this working as expected.

First, create a file called “phpsource.php”, in this file paste the following code:

<?php
if (substr($_GET['file'],strpos($_GET['file'],’.')) == ‘.phps’) {
highlight_file($_GET['file']);
}
?>

Then, in your “.htaccess”, paste the following code:

RewriteRule ^(.+\.phps)$ phpsource.php?file=$1 [L]

Note: If you don’t already have rewrites turned on in your “.htaccess” file, you will also need the line “RewriteEngine On” at the top.

What this will do is pass all “.phps” files through your “phpsource.php” script, and output a highlighted version.

The benefits of this solution is that it’s portable (will work on any server); it won’t(/shouldn’t) break when you upgrade apache or PHP; it’s pretty secure as it’ll only handle .phps files, as expected; it’s quick and effective.

ShareThis

OpenCart all began because (at the time) the leading open source e-commerce solution out there was not very good, to say the least.

The first notable release was OpenCart v0.5 back in late 2006 and has been gaining momentum ever since.

The project is lead by Daniel Kerr, and I have also recently joined the team.

Download OpenCart v0.7.8

If you need any assistance with OpenCart, you can find me on the OpenCart Community Forums, and on the OpenCart Google Code project site.

Enjoy!

ShareThis

$longip(address)

Converts an IP address into a long value and vice-versa.

$longip(158.152.50.239)  returns 2660774639

$longip(2660774639)       returns 158.152.50.239

What I was originally trying to do was increase an IP by 1, but due to the octets only allowing up to 255, this became increasingly difficult to do.

What I decided to do in the end was convert the IP to a “longip” then increase it by 1, then convert the IP BACK to normal IP.

This required a way to convert an IP to and from longIP, I was told it could be done purely using shell script, here’s what I did…

I decided that shell script wasn’t powerful enough for what I wanted, and that I could do it easier in perl, this is the result:

#!/usr/bin/perl

# longip by HM2K 2008 (Updated: 17/01/08)

# Description: Converts (Short) IPs to Long Ips and visa versa.
# Usage: ./longip.pl <ip>

use warnings;
use strict;
use Socket;

sub longip {
my $input=shift;
if ($input =~ /\d+\.\d+\.\d+\.\d+/) { return ip2long($input); }
else { return long2ip($input); }
}

sub ip2long { return unpack(”l*”, pack(”l*”, unpack(”N*”, inet_aton(shift)))); }

sub long2ip { return inet_ntoa(pack(”N*”, shift)); }

print longip(shift);

Thanks for the assistance from #perlhelp (EFnet).

It’s also worth noting that cls (EFnet) created a full shell script version called “ipconv.sh”, which is about 50 long lines in total (too long for such a simple task imo). If you ask him (or me) nicely, you may receive a copy.

Enjoy!

ShareThis

As I had known him for a long time, I felt obliged to help out, plus I was now interested in the questions that would be asked.

Based on what had been said I knew they were going to be questions on defining what a hacker is and what a hacker does, something i’ve been interested in defining for quite some time.

Here’s what I said…

What would you say a hacker was in your eyes?

It’s said that a hacker is not defined by the hacker but by others. You soon come to realise the extent of this when the media use this term in an article about you.

How I see it is the term is used based on a level of understanding. For your average Joe, who knows very little about computers outside of your basic office package may view someone who does, as a hacker.

However, it’s likely that these more knowledgeable people do not view themselves as a hacker, and also have formed their own opinion of what a hacker is or more importantly, what a hacker isn’t.

Do you know about the history of Hackers?

Traditionally a “hacker” was defined as a programmer who “hacked” up bits of code. It’s since been defined in many different ways.

Ever since the first network was constructed, there has always been hackers. If you build a system people will inevitably mess with it.

What type of things do they do?

These days hackers are most notorious for breaching the security of a system. However, hackers come in different forms and colours.

Have you ever heard of the hacker ethic?

Well, you have your white hat hackers, commonly known as “security experts” and are often employed by companies to test the security of systems if not, to prove a point or as a proof of concept. Ultimately their skills are used for good purposes, sort of hackers with morals if you like.

On the other hand you have your black hat hackers who use their skills for various “bad” purposes, whether it be for illegal activities, or purely malicious.

You also have your grey hat hackers, a cross between the two. They generally do bad things, such as breach system security, to achieve things that are in their mind, are morally “not bad” or sometimes even good. Usually for personal gain.

So do you think a modder different from a hacker?

In my opinion, and in the context of software engineering a hacker is someone who essentially makes the application do something it wouldn’t normally do, which is effectively exactly what a modder is.

If you look at some of the most commonly used software applications used at the very core of the internet including Apache HTTPD and BIND, you’ll soon find out that they are made up from many of hacks and workarounds.

However, this type of hacker would be a software hacker, a distant relative of the security expert.

So how did you get started and involved in it?

I have always been interested in computers, but I have also always been interested in how things work.

When I was young I didn’t understand enough about the “hacking” to actually be involved with it. I did however learn a little about phreaking and then software cracking.

I found it very interesting that with the changes of a few bytes in an executable file you could turn a piece of software from trial to registered. To achieve this you must understand the basics of reverse engineering software. Often a painstakingly slow process, with little reward at the end.

Eventually through increasing use of the internet, I began to learn about web servers, mail servers, rfcs, dns, irc and all sorts of scripting languages including perl and php.

It wasn’t long before I begin hacking around with these platforms and protocols.

How did you learn?

I’m very much a hands on learner. I learn by example, and trial and error, not by reading a book.

Having said that, I have read books on all sorts of computer related topics, but I find them more useful as a resource than a method of learning.

It’s taken me quite some time to fully understand some aspects of the way the things work, especially online. I think learning the basics of how computers and the internet works is a very important part of education.

It concerns me that the kids of today, although they know how to use computers and the internet, do not understand how it works.

What do you make of the new generation of hackers?

I don’t think there is a new generation of hackers. What I see are the same old spammers, but all new developers.

Hacking has evolved.

ShareThis

I’m sure we’re all familiar with URLs that look like this:

http://www.example.com/?nav=page

These type of URLs aren’t particularly “friendly”, inf act they are so ugly that even Google doesn’t like them!

Google suggests that search engines do not like dynamic URLs as much as static URLs.

“static” or “friendly” versions of the above URL could be as follows:

http://www.example.com/page.html

Apache’s mod_rewrite can be easily used via a file called “.htaccess” to turn dynamic urls into friendly urls.

Here is an example of how it’s done:

#Turn on the Rewrite Engine
RewriteEngine on
#Set the base path
RewriteBase /
#Check that the lookup isn’t an existing file
RewriteCond %{REQUEST_FILENAME} !-f
#Check that the lookup isn’t an existing directory
RewriteCond %{REQUEST_FILENAME} !-d
#Check that the file isn’t index.php (avoid looping)
RewriteCond %{REQUEST_URI} !^index\.php$
#Force all .html lookups to the index file
RewriteRule (.+)*\.html index.php?nav=$1 [QSA,L]
#Note: QSA=query string append;L=Last, no more rules

This will rewrite all paths ending in “.html” to your index file.

From there, it’s simply a case of tailoring the rewrite to your requirements.

Checkout the mod_rewrite cheat sheet for more help on rewrites.

If you ARE using PHP, a better way might be to just hand over ALL the path information to your “index.php” and handle it from there, the rewrite to do that looks something like this:

RewriteEngine on
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !^index\.php$
RewriteRule ^(.+)$ index.php/$1 [QSA,L]

As per above this will only rewrite paths that don’t exist.

In your “index.php”, you can parse $_SERVER['PATH_INFO'] (and sometimes $_SERVER['ORIG_PATH_INFO']) for the path information.

ShareThis

We all know what an email address looks like, we see them and use them every single day. But how do you know if it’s valid or not? The next obvious question should be, what defines a valid email address?

This is what I intend on investigating.

Before you begin, I would like you make you aware of the difference between validation and verification, which is as follows:

Validation is a check to ensure it is true to the specification (eg: is the number N digits long?). Not to be confused with verification which is a check to ensure it is correct within the intended system (eg: does the number work when phoned?).

A good starting point for anyone to investigating what anything is, is Wikipedia. So, as to make this easy to follow, that’s where we’re going to start, by looking at the “E-mail address” article.

As you read the article, you’ll soon find out about the limitations and validation (not to be confused with authentication) set by the RFCs. The earliest RFC with regards to email was [RFC822], which was made obsolete by [RFC2822]. There are other RFCs you should perhaps also pay attention to which are listed in the article, however I intend on going over these later.

To fully understand how to find out what a valid email address is, we need to fully understand what an RFC is and why we need them.

An RFC (request for comments) essentially is a way in which internet developers can set standards and protocols. The RFCs we need to be focusing on are the ones relating to email, as they will tell us exactly what defines an email address as an email address. Thus in order for us to fully understand what defines an email as valid, we MUST read the RFCs.

RFCs however, aren’t easy, they are written what appears to be a mystical language, that looks like English, but it isn’t. Okay, so maybe it’s not that bad, but it isn’t exactly a straight forward task to translate it into “Plain English”.

After reading I Knew How To Validate An Email Address Until I Read The RFC and Paul Gregg’s Demonstrating why email regexs are poor, I knew this wasn’t going to be easy.

To utilise the specification written in the RFC, we need to convert it into a usable language. In this case we will be using regular expressions within PHP. This article assumes you understand PHP and regular expressions, or will at least try…

And so I decided to start translating [RFC2822] into PHP based regular expressions.

The RFC often provides binary encoded US-ASCII characters and standard characters, in most cases I will translate them to hexadecimal encoding using chr(), orc() and dechex() (eg: %d109 -> chr(109) -> m -> orc(m) -> 109 -> dechex(109) -> \\x6D).

Note: The PHP code here is for display purposes only, it may not actually work due to the changes wordpress makes to the formatting (in particular to the double quotes), if you require the proper code, it is available on request.

FROM: General Description [RFC2822 Section 2.1]
Messages are divided into lines of characters. A line is a series of
characters that is delimited with the two characters carriage-return
and line-feed; that is, the carriage return (CR) character (ASCII
value 13) followed immediately by the line feed (LF) character (ASCII
value 10). (The carriage-return/line-feed pair is usually written in
this document as “CRLF”.)

$CR = “\\x0d”;
$LF = “\\x0a”;
$CRLF = “(?:$CR$LF)”;

FROM: Primative Tokens [RFC2822 Section 3.2.1]

The following are primitive tokens referred to elsewhere in this
standard, but not otherwise defined in [http://tools.ietf.org/html/rfc2234 RFC2234]. Some of them will
not appear anywhere else in the syntax, but they are convenient to
refer to in other parts of this document.

NO-WS-CTL = %d1-8 / ; US-ASCII control characters
%d11 / ; that do not include the
%d12 / ; carriage return, line feed,
%d14-31 / ; and white space characters
%d127
text = %d1-9 / ; Characters excluding CR and LF
%d11 /
%d12 /
%d14-127 /
obs-text
specials = “(” / “)” / ; Special characters used in
“<” / “>” / ; other parts of the syntax
“[" / "]” /
“:” / “;” /
“@” / “\” /
“,” / “.” /
DQUOTE

No special semantics are attached to these tokens. They are simply
single characters.

$NO_WS_CTL = “[\\x01-\\x08\\x0b\\x0c\\x0e-\\x1f\\x7f]“;
$text = “[\\x01-\\x09\\x0b\\x0c\\x0e-\\x7f]“;
$DQUOTE = “\\x22″;
$specials = “[\\x28\\x29\\x3c\\x3e\\x5b\\x5d\\x3a\\x3b\\x40\\x5c\\x2c\\x2e$DQUOTE]“;

FROM: Miscellaneous obsolete tokens [RFC2822 Section 4.1]
obs-qp = “\” (%d0-127)
obs-text = *LF *CR *(obs-char *LF *CR)
obs-char = %d0-9 / %d11 / ; %d0-127 except CR and
%d12 / %d14-127 ; LF

$obs_qp = “(?:\\x5c[\\x00-\\x7f])”;
$obs_char = “[\\x00-\\x09\\x0b\\x0c\\x0e-\\x7f]“;
$obs_text = “(?:$LF*$CR*(?:$obs_char$LF*$CR*)*)”;

FROM: Structured Header Field Bodies [RFC2822 Section 2.2.2]
the space (SP, ASCII value 32) and horizontal tab (HTAB, ASCII value 9) characters
(together known as the white space characters, WSP)

$WSP = “[\\x20\\x09]“;

FROM: Obsolete folding white space [RFC2822 Section 4.2]
obs-FWS = 1*WSP *(CRLF 1*WSP)

$obs_FWS = “(?:$WSP+(?:$CRLF$WSP+)*)”;

FROM: Quoted characters [RFC2822 Section 3.2.2]
quoted-pair = (”\” text) / obs-qp

$quoted_pair = “(?:\\x5c$text|$obs_qp)”;

FROM: Folding white space and comments [RFC2822 Section 3.2.3]
FWS = ([*WSP CRLF] 1*WSP) / ; Folding white space
obs-FWS
ctext = NO-WS-CTL / ; Non white space controls

%d33-39 / ; The rest of the US-ASCII
%d42-91 / ; characters not including “(”,
%d93-126 ; “)”, or “\”
ccontent = ctext / quoted-pair / comment
comment = “(” *([FWS] ccontent) [FWS] “)”
CFWS = *([FWS] comment) (([FWS] comment) / FWS)

$FWS = “(?:(?:(?:$WSP*$CRLF)?$WSP*)|$obs_FWS)”;
$ctext = “(?:$NO_WS_CTL|[\\x21-\\x27\\x2A-\\x5b\\x5d-\\x7e])”;
$ccontent = “(?:$ctext|$quoted_pair)”;
/* NOTICE: ‘ccontent’ translated only partially to avoid an infinite loop. */
$comment = “(?:\\x28((?:$FWS?(?:$ccontent|(?1)))*$FWS?\\x29))”;
$CFWS = “((?:$FWS?$comment)*(?:(?:$FWS?$comment)|$FWS))”;

FROM: Atom [RFC2822 Section 3.2.4]
atext = ALPHA / DIGIT / ; Any character except controls,
“!” / “#” / ; SP, and specials.
“$” / “%” / ; Used for atoms
“&” / “‘” /
“*” / “+” /
“-” / “/” /
“=” / “?” /
“^” / “_” /
“`” / “{” /
“|” / “}” /
“~”
atom = [CFWS] 1*atext [CFWS]
dot-atom = [CFWS] dot-atom-text [CFWS]
dot-atom-text = 1*atext *(”.” 1*atext)

$ALPHA = ‘[\\x41-\\x5a\\x61-\\x7a]‘;
$DIGIT = ‘[\\x30-\\x39]‘;
$atext = “(?:$ALPHA|$DIGIT|[\\x21\\x23-\\x27\\x2a\\x2b\\x2d\\x2f\\x3d\\x3f\\x5e\\x5f\\x60\\x7b-\\x7e])”;
$atom = “(?:$CFWS?$atext+$CFWS?)”;
$dot_atom_text = “(?:$atext+(?:\\x2e$atext+)*)”;
$dot_atom = “(?:$CFWS?$dot_atom_text$CFWS?)”;

FROM: Quoted strings [RFC2822 Section 3.2.5]
qtext = NO-WS-CTL / ; Non white space controls

%d33 / ; The rest of the US-ASCII
%d35-91 / ; characters not including “\”
%d93-126 ; or the quote character
qcontent = qtext / quoted-pair
quoted-string = [CFWS]
DQUOTE *([FWS] qcontent) [FWS] DQUOTE
[CFWS]

$qtext = “(?:$NO_WS_CTL|[\\x21\\x23-\\x5b\\x5d-\\x7e])”;
$qcontent = “(?:$qtext|$quoted_pair)”;
$quoted_string = “(?:$CFWS?\\x22(?:$FWS?$qcontent)*$FWS?\\x22$CFWS?)”;

FROM: Miscellaneous tokens [RFC2822 Section 3.2.6]
word = atom / quoted-string

$word = “(?:$atom|$quoted_string)”;

Obsolete Addressing [http://tools.ietf.org/html/rfc2822#section-4.4 RFC2822 Section 4.4]
obs-local-part = word *(”.” word)
obs-domain = atom *(”.” atom)

$obs_local_part = “(?:$word(?:\\x2e$word)*)”;
$obs_domain = “(?:$atom(?:\\x2e$atom)*)”;

FROM: Addr-spec specification [RFC2822 Section 3.4.1]

addr-spec = local-part “@” domain
local-part = dot-atom / quoted-string / obs-local-part
domain = dot-atom / domain-literal / obs-domain
domain-literal = [CFWS] “[" *([FWS] dcontent) [FWS] “]” [CFWS]
dcontent = dtext / quoted-pair
dtext = NO-WS-CTL / ; Non white space controls

%d33-90 / ; The rest of the US-ASCII
%d94-126 ; characters not including “[",
; "]“, or “\”

$dtext = “(?:$NO_WS_CTL|[\\x21-\\x5a\\x5e-\\x7e])”;
$dcontent = “(?:$dtext|$quoted_pair)”;
$domain_literal = “(?:$CFWS?\\x5b(?:$FWS?$dcontent)*$FWS?\\x5d$CFWS?)”;
$local_part = “(?:$dot_atom|$quoted_string|$obs_local_part)”;
$domain = “(?:$dot_atom|$domain_literal|$obs_domain)”;
$addr_spec = “($local_part\\x40$domain)”;

There we have it, how to validate an email address according to [RFC2822].

However, let’s stop right there and reflect on what we have here. What we have is regular expression based on [RFC2822] that must be correct, but does it work? are there any problems? Well yes, there are some problems…

• The comments, and content of comments have an infinite loop due to possible nested comments.
• It does not appear to validate folding white space where it should.
• It does not correctly validate domain literals (IP addresses), they are simply not validated by [RFC2822], which means that IP addresses that (under current protocol) are invalid (eg: 300.300.300.300) .
• Domain names are not validated correctly either, IP addresses are allowed, when they shouldn’t be, and certain characters are allowed in places they shouldn’t, like dash (-) at the start or end of a domain name (eg: test@-example.com).
• Length is no concern, email addresses can be as long as you like, much like the regex.
• There are many more RFC’s to investigate and translate before we can fully validate all parts of an email address.
• The email address validation regular expression according to [RFC2822] ALONE is almost 20,000 characters long, that’s BEFORE we look into solving these other issues.

This is simply unacceptable.

Although there are fixes and workarounds, in the form of stripping, and further validation based on other RFCs I began to feel that this wasn’t really suitable for validating real world email addresses.

Ultimately I feel that unless you’re building an mail client or an mail server sticking so strictly to the RFC (especially [RFC2822]) isn’t always going to give you the best results, in real world situations.

Look around, email addresses in the real world aren’t so strict and are far more loosely defined.

• No folding white space (FWS) - I’ve never seen a multi-line email address field for a single address.
• No comments (CFWS) - Comments simply do not belong in an email address, they can go else where.
• No quotes - When was the last time you saw quoted text in an email address?
• No IP addresses, domains only - They are only used in temporary circumstances, not live.
• No new lines - they could result in “email header injection”.
• Reasonable lengths - both parts, and the whole thing needs to be kept to a reasonable maximum length.
• The domain part doesn’t need to be so strict - We can easily verify it later using DNS.
• TLDs need to be future proof - Don’t restrict yourself to a set list. Don’t forget about IDN.
• Most RFCs are outdated, and unreliable - Remember they are technical documents for servers and clients, but not for real world situations.
• Only need to validate real world email addresses - Don’t be concerned with edge case test samples.

Hence forth, the rest of this article will concentrate on this “less strict” or “LOOSE” specification, defined by real world situations, rather than technical.

Upon going back to the drawing board I discovered [RFC3696], written by the guy who wrote [RFC2881] (SMTP). This will give us the basics of what is required for a valid email address.

[RFC3696 Section 3] entitled “Restrictions on email addresses” states:

Contemporary email addresses consist of a “local part” separated from a “domain part” (a fully-qualified domain name) by an at-sign (”@”).

We’ll look at the “local part” first.

First off, as above, we will be overlooking quoted forms.

[RFC3696 Section 3]

“These quoted forms are rarely recommended, and are uncommon in practice”

We’ll ignore anything about using quotes, “real world” email addresses don’t contain quotes.

[RFC3696 Section 3]

Without quotes, local-parts may consist of any combination of alphabetic characters, digits, or any of the special characters

      ! # $ % & ' * + - / = ?  ^ _ ` . { | } ~

period (”.”) may also appear, but may not be used to start or end the local part, nor may two or more consecutive periods appear.

“alphabetic characters” are “a-zA-Z”, digits are “0-9″, and special characters appear as above, in PHP based regex, the combination or “comb” for short, looks like this:

$comb = ‘[a-zA-Z0-9!#$%&\'*+\/=?^`{|}~.-]‘;

You’ll notice that some of the special characters have backslashes (\) next to them, this is to “escape” them when being used as a regular expression, as they normally hold special meaning. Also the dash (-) symbol was moved to the end so that it did not act as “between”.

Putting this information together, including the bit about periods appearing in the middle, but never two together, that appears like this:

$local_part = “($comb(?:\.$comb)?)+”;

That’s the local part done. Now onto the domain part, which we’ll base on [RFC3696 Section 2].

the labels (words or strings separated by periods) that make up a domain name must consist of only the ASCII [ASCII] alphabetic and numeric characters, plus the hyphen. No other symbols or punctuation characters are permitted, nor is blank space. If the hyphen is used, it is not permitted to appear at either the beginning or end of a label. There is an additional rule that essentially requires that top-level domain names not be all- numeric.

Most internet applications that reference other hosts or systems assume they will be supplied with “fully-qualified” domain names, i.e., ones that include all of the labels leading to the root, including the TLD name. Those fully-qualified domain names are then passed to either the domain name resolution protocol itself or to the remote systems. Consequently, purported DNS names to be used in applications and to locate resources generally must contain at least one period (”.”) character.

A DNS label may be no more than 63 octets long.

Although it doesn’t say it as such in [RFC3696], we are on the understanding that periods cannot appear at the start or end of a domain name, but that is of course because periods are only used to “separate labels”.

When building this I had some issues to overcome…

• DNS labels cannot start or end with a dash (-), however two or more are allowed together in a label.
• TLDs cannot be “all numerics”, TLDs are generally all alphabetical, APART from IDN TLDs, which start with “xn--”, followed by a string of ASCII characters. This does throw a spanner in the works, however, there’s one consistency which is seen throughout, which is that all valid TLDs always start with at least 1 alphabetical character, this is what we will check for.
• TLDs are generally between 2 and 6 characters, IDN TLDs changes all this, as I have seen IDN TLDs as long as 18 characters in length, the RFC, however says 63.
• A label can be 1 character long.

Finally, we need to ensure that the length is correct. For this we need to read the [RFC3696 errata].

   In addition to restrictions on syntax, there is a length limit on
   email addresses.  That limit is a maximum of 64 characters (octets)
   in the "local part" (before the "@") and a maximum of 255 characters
   (octets) in the domain part (after the "@") for a total length of 320
   characters. However, there is a restriction in RFC 2821 on the length of an
   address in MAIL and RCPT commands of 256 characters.  Since addresses
   that do not fit in those fields are not normally useful, the upper
   limit on address lengths should normally be considered to be 256.

When it comes to dealing with lengths in regular expressions, it can often become very confusing, so I wrote this little peice of advice to refer to…

(it){X,Y} means “see it between X and Y more times”

What we need to do in terms of length is as follows:

• The “local-part” total length must be no longer than 64 characters.
• The “domain-part” total length must be no longer than 255 characters.
• Each “dns-label” total length must be no longer than 63 characters.
• The entire “email address” total length must be no longer than 256 characters.

Put this together with the fact that certain elements cannot start or end with certain characters, it makes it difficult to correctly place the end check. Here’s a run down of that:

• The “local-part” cannot start or end with a period (.)
• The “local-part” must not have two periods together
• A “dns-label” cannot start or end with a dash (-)

I found that I was unable to satisfy both the lengths and the character placements in a single regular expression. This forced me to make a decision, I could have one or the other, or neither.

I figured that lengths actually hold very little value in validation. Providing the email looks right specific lengths won’t matter. Besides, we don’t need regular expressions in order to check lengths, it’s a very simple principle. It’s also worth noting that I discovered the local part CAN be over 64 characters, check it out.

After playing around with dots and dashes in various places in email addresses on various servers and clients I soon discovered that it wasn’t as strict as I had first perceived. I found many examples of dots and dashes where they shouldn’t be, mainly at on the end of dns-labels (such as “x-.x.com”). Ultimately, at least for the “local-part”, it’s down to the user. For both parts verification should be used instead.

So now the local-part now looks like this:

$local_part = “[a-zA-Z0-9!#\$%&\'\*\+\/=\?\^_`\{\|\}~\.-]+”;

And FINALLY, the domain part looks like this:

$consists = ‘[a-zA-Z0-9][a-zA-Z0-9-]*’;
$label = “(?:$consists(?:\.$consists)?)”;
$tldlabel = “(?:[a-zA-Z][a-zA-Z0-9-]+)”;
$domain = “$label\.$tldlabel”;

We now need to bring the two parts back together, separated by an at-sign (@)…

$addr_spec=”$local_part@$domain”;

Once you’ve added the syntax to match the start and end position, the resulting regular expression, looks something like this:

/^[a-zA-Z0-9!#$%&\'*+\/=?^_`{|}~.-]+@(?:[a-zA-Z0-9][a-zA-Z0-9-]*(?:\.[a-zA-Z0-9][a-zA-Z0-9-]*)?)+\.(?:[a-zA-Z][a-zA-Z0-9-]+)$/i

I’m sure some of you have probably been shouting all the way through this saying that you can shorten the regex, I purposely didn’t do this to make it easier to follow. However you can shorten [a-zA-Z] by using the “case insensitive” modifier allowing you to remove “A-Z”, it also might be worth noting that you can use “\d” instead of “0-9″.

Here’s what I did:

$addr_spec=str_replace(’a-zA-Z’,'a-z’,$addr_spec);
$addr_spec=str_replace(’0-9′,’\d’,$addr_spec);

You may also wish to take it further and consider replacing “a-z\d” with “\w”, and also removing the extra “_”, since “\w” means word, which includes “a-zA-Z0-9_”.

Here’s how it looks:

/^[\w!#$%&\'*+\/=?^`{|}~.-]+@(?:[a-z\d][a-z\d-]*(?:\.[a-z\d][a-z\d-]*)?)+\.(?:[a-z][a-z\d-]+)$/i

Update: Due to recent vulnerabilities in PHP’s very own email address validation regex (FILTER_VALIDATE_EMAIL) used in the var_filter function, it’s recommended that you use the /D modifier, that will prevent newlines from matching. ie:

/^[\w!#$%&\'*+\/=?^`{|}~.-]+@(?:[a-z\d][a-z\d-]*(?:\.[a-z\d][a-z\d-]*)?)+\.(?:[a-z][a-z\d-]+)$/iD

Final thoughts

Learning how to correctly validate an email address has been one of the most stressful and time consuming things i’ve had to do in web development.

RFCs aren’t easy to understand, they are a complete minefield, and it results in something that is incomprehensible and unmaintainable.

There’s a lot that can be said for proper validation, so many people get it wrong, and it can mean the difference between a sale and no sale, but there’s a difference between doing it properly based strictly on technical specification and doing it properly for real world situations.

In order to validate correctly, you must be in touch with the real world, and not get caught up too much in the technical documentation, otherwise you will find yourself far from the original objective.

Thus a lot can be said about the outdated RFCs, and the people who write them. The technical specification is so far out of touch with reality it does not actually work in practice.

Having said all this, of course validation has it’s limitations and can only do so much. Once you’ve validated the email address to the best of your ability without compromising too much resources, verification is the next step.

This article for intent and purpose set out to validate an email address. Although basic levels of verification can be done very easily, I feel that it goes beyond the scope of this article.

For more information with regards to email address verification, I suggest you look into the Simple Mail Transfer Protocol (SMTP), details can be found in [RFC2821], you may also be interested in the getmxrr() function. Also consider the use of DNS to verify the domain name.

I hope you’ve enjoyed reading this article, it took me a long time to complete, and was quite stressful, but I feel satisfied that I am now fully qualified to validate email addresses to a satisfactory level. I hope that now, you are too.

I look forward to your comments.

Resources

• Perl’s Mail::RFC822::Address
• Cal’s is_valid_email_address PHP function
• sinful-music.com’s mime_extract_rfc2822_address
• SimonSlick’s Validate Email Address Format
• Jacob Santos’s “Stop Doing Email Validation the Wrong Way” rant.
• Validate email addresses using regular expressions
• ilovejackdaniels.com on email address validation

ShareThis

The problem is the moment that I use another application the focus is taken away from the Firefox window and it goes into the background. This is no good as I can no longer see the video.

I decided to investigate a solution that could keep the Mozilla Firefox window “Always on Top”…

Like most people my first port of call was the Mozilla Firefox community, I made a post called “Always on top“, which asked if there was javascript or a plugin somewhere that can force the window to always be on top.

I quickly discovered that there wasn’t going to be any kind of easy way to achieve this using Firefox alone.

What I needed was a third party application, ideally something freeware, or even better open source.

Here’s a short list of what I found:

• Actual Window Manager - $49.95
  • Seems rather expensive for something that should be free.
• Keep On Top - Freeware
  • Very basic, doesn’t really offer anything special
• AbstractPath PowerMenu - Freeware
  • Gives you context menus that offer: Always On Top, Transparency and Minimize To Tray.
• RBTray - Open Source
  • Offers the context menus: Always On Top, and Minimize To Tray
• WinPin - Open Source
  • Gives you a little pin to the left of your “Minimise” button that will “pin” the window on top.

All in all, I’d say WinPin does the job just fine, if you also want to Minimise to Tray too, try RBTray.

ShareThis

History:

Seen v1.1 - 20/05/08 Lastspoke can work from seen.log now too, added relay so can be used locally, redid input and output, reset your log file
Seen v1.03 - 09/06/06 now has lastspoke, other functions were fixed too.
Seen v1.02 - Cleaned up the script, added this file.
Seen v1.01 - Fixed a few bugs and added new features.
Seen v1.0 - Initial Public Release - Basic Code.

Download seen.mrc

ShareThis

The result is this list of over 50 PHP optimisation tips…

Enjoy!

1. echo is faster than print. [Citation]
2. Wrap your string in single quotes (’) instead of double quotes (”) is faster because PHP searches for variables inside “…” and not in ‘…’, use this when you’re not using variables you need evaluating in your string. [Citation]
3. Use sprintf instead of variables contained in double quotes, it’s about 10x faster. [Citation]
4. Use echo’s multiple parameters (or stacked) instead of string concatenation. [Citation]
5. Use pre-calculations, set the maximum value for your for-loops before and not in the loop. ie: for ($x=0; $x < count($array); $x), this calls the count() function each time, use $max=count($array) instead before the for-loop starts. [Citation]
6. Unset or null your variables to free memory, especially large arrays. [Citation]
7. Avoid magic like __get, __set, __autoload. [Citation]
8. Use require() instead of require_once() where possible. [Citation]
9. Use full paths in includes and requires, less time spent on resolving the OS paths. [Citation]
10. require() and include() are identical in every way except require halts if the file is missing. Performance wise there is very little difference. [Citation]
11. Since PHP5, the time of when the script started executing can be found in $_SERVER[’REQUEST_TIME’], use this instead of time() or microtime(). [Citation]
12. PCRE regex is quicker than EREG, but always see if you can use quicker native functions such as strncasecmp, strpbrk and stripos instead. [Citation]
13. When parsing with XML in PHP try xml2array, which makes use of the PHP XML functions, for HTML you can try PHP’s DOM document or DOM XML in PHP4. [Citation]
14. str_replace is faster than preg_replace, str_replace is best overall, however strtr is sometimes quicker with larger strings. Using array() inside str_replace is usually quicker than multiple str_replace. [Citation]
15. “else if” statements are faster than select statements aka case/switch. [Citation]
16. Error suppression with @ is very slow. [Citation]
17. To reduce bandwidth usage turn on mod_deflate in Apache v2 [Citation] or for Apache v1 try mod_gzip. [Citation]
18. Close your database connections when you’re done with them. [Citation]
19. $row[’id’] is 7 times faster than $row[id], because if you don’t supply quotes it has to guess which index you meant, assuming you didn’t mean a constant. [Citation]
20. Use <?php … ?> tags when declaring PHP as all other styles are depreciated, including short tags. [Citation]
21. Use strict code, avoid suppressing errors, notices and warnings thus resulting in cleaner code and less overheads. Consider having error_reporting(E_ALL) always on. [Citation]
22. PHP scripts are be served at 2-10 times slower by Apache httpd than a static page. Try to use static pages instead of server side scripts. [Citation]
23. PHP scripts (unless cached) are compiled on the fly every time you call them. Install a PHP caching product (such as memcached or eAccelerator or Turck MMCache) to typically increase performance by 25-100% by removing compile times. You can even setup eAccelerator on cPanel using EasyApache3. [Citation]
24. An alternative caching technique when you have pages that don’t change too frequently is to cache the HTML output of your PHP pages. Try Smarty or Cache Lite. [Citation]
25. Use isset where possible in replace of strlen. (ie: if (strlen($foo) < 5) { echo “Foo is too short”; } vs. if (!isset($foo{5})) { echo “Foo is too short”; } ). [Citation]
26. ++$i is faster than $ i++, so use pre-increment where possible. [Citation]
27. Make use of the countless predefined functions of PHP, don’t attempt to build your own as the native ones will be far quicker; if you have very time and resource consuming functions, consider writing them as C extensions or modules. [Citation]
28. Profile your code. A profiler shows you, which parts of your code consumes how many time. The Xdebug debugger already contains a profiler. Profiling shows you the bottlenecks in overview. [Citation]
29. Document your code. [Citation]
30. Learn the difference between good and bad code. [Citation]
31. Stick to coding standards, it will make it easier for you to understand other people’s code and other people will be able to understand yours. [Citation]
32. Separate code, content and presentation: keep your PHP code separate from your HTML. [Citation]
33. Don’t bother using complex template systems such as Smarty, use the one that’s included in PHP already, see ob_get_contents and extract, and simply pull the data from your database. [Citation]
34. Never trust variables coming from user land (such as from $_POST) use mysql_real_escape_string when using mysql, and htmlspecialchars when outputting as HTML. [Citation]
35. For security reasons never have anything that could expose information about paths, extensions and configuration, such as display_errors or phpinfo() in your webroot. [Citation]
36. Turn off register_globals (it’s disabled by default for a reason!). No script at production level should need this enabled as it is a security risk. Fix any scripts that require it on, and fix any scripts that require it off using unregister_globals(). Do this now, as it’s set to be removed in PHP6. [Citation]
37. Avoid using plain text when storing and evaluating passwords to avoid exposure, instead use a hash, such as an md5 hash. [Citation]
38. Use ip2long() and long2ip() to store IP addresses as integers instead of strings. [Citation]
39. You can avoid reinventing the wheel by using the PEAR project, giving you existing code of a high standard. [Citation]
40. When using header(’Location: ‘.$url); remember to follow it with a die(); as the script continues to run even though the location has changed or avoid using it all together where possible. [Citation]
41. In OOP, if a method can be a static method, declare it static. Speed improvement is by a factor of 4. [Citation].
42. Incrementing a local variable in an OOP method is the fastest. Nearly the same as calling a local variable in a function and incrementing a global variable is 2 times slow than a local variable. [Citation]
43. Incrementing an object property (eg. $this->prop++) is 3 times slower than a local variable. [Citation]
44. Incrementing an undefined local variable is 9-10 times slower than a pre-initialized one. [Citation]
45. Just declaring a global variable without using it in a function slows things down (by about the same amount as incrementing a local var). PHP probably does a check to see if the global exists. [Citation]
46. Method invocation appears to be independent of the number of methods defined in the class because I added 10 more methods to the test class (before and after the test method) with no change in performance. [Citation]
47. Methods in derived classes run faster than ones defined in the base class. [Citation]
48. A function call with one parameter and an empty function body takes about the same time as doing 7-8 $localvar++ operations. A similar method call is of course about 15 $localvar++ operations. [Citation]
49. Not everything has to be OOP, often it is just overhead, each method and object call consumes a lot of memory. [Citation]
50. Never trust user data, escape your strings that you use in SQL queries using mysql_real_escape_string, instead of mysql_escape_string or addslashes. Also note that if magic_quotes_gpc is enabled you should use stripslashes first. [Citation]
51. Unset your database variables (the password at a minimum), you shouldn’t need it after you make the database connection.
52. RTFM! PHP offers a fantastic manual, possibly one of the best out there, which makes it a very hands on language, providing working examples and talking in plain English. Please USE IT! [Citation]

If you still need help, try #PHP on the EFnet IRC Network. (Read the !rules first).

Also see:

• an Excellent Article about optimizing PHP by John Lim
• PEAR coding standards
• PHP best practices by ez.no (Use left and right keys to scroll through the pages)
• Tuning Apache and PHP for Speed on Unix
• Premature Optimisation
• PHP and Performance
• Performance Tuning PHP
• Develop rock-solid code in PHP
• 12 PHP optimization tips
• 10 things you (probably) didn’t know about PHP

Think you’re a PHP guru now? See if you can answer these questions.

ShareThis

Geek in the Park is a day-long event for geeks (mainly web developers) to have a get together.

The event is going to be held in Jephson Gardens, Leamington Spa, Warwickshire.

The Picnic during the day, followed by The Discussion in the evening. The event starts on Saturday at noon and everything should wrap up by around 11pm.

…and yes, I will be attending.

So, come see me at Geek in the Park on Saturday 9th August 2008. Put it in your diary!

I aim to get there around mid-day, but have been known to be fashionably late.

You’ll find me listed on both the Upcoming and Facebook event pages.

Don’t forget to visit the Geek in the Park website and add your email address to the announcements.

For those of you on IRC, you can visit #webdev @ EFnet to discuss it further.

See you there!

ShareThis