Tag Archives: PHP

Installing IMAP extension for PHP on Mountain Lion

Based on Dao Hoang Son’s tutorial (itself based on Dan Spencer’s Lion tutorial), as well as a few corrections of my own, I came up with the following script. It fetches and installs University of Washington’s IMAP library, then the PCRE – Perl Compatible Regular Expressions library, and finally the PHP IMAP extension itself.

Please study the script yourself before running it, or run it line by line. It performs no error checking, meaning it might totally wreck your machine — and I’m not responsible if it does. Keep a Time Machine backup around and unplugged from the computer, in case it does.

The script wasn’t yet tested in its complete form; it’s an approximate transcript of commands I ran in shell. But since I’ll keep it around in case I ever need to re-run it, I’m fairly certain it works.

UPDATE December 24th 2012 – Merry Christmas! I’ve applied corrections based on Mehmet’s comment. He also comments you need to install autoconf before running the script (so phpize can work). I already had it installed.

Filesizes for stuff I downloaded: 1.990.304 – imap-2007f.tar.gz, 1.539.766 – pcre-8.20.tar.gz, 12.926.535 – PHP-5.3.15.tar.gz

#!/bin/bash
BUILDDIR=/tmp/phpimapmountainlion

mkdir "$BUILDDIR"
echo " "
echo "= FETCHING AND INSTALLING IMAP"
echo " "
cd "$BUILDDIR"
wget -c ftp://ftp.cac.washington.edu/imap/imap-2007f.tar.gz
rm -rf imap-2007f
tar xvvfz imap-2007f.tar.gz
cd imap-2007f
make osx EXTRACFLAGS="-arch i386 -arch x86_64 -g -Os -pipe -no-cpp-precomp"
sudo mkdir -p /usr/local/imap-2007f/include
sudo cp c-client/*.h /usr/local/imap-2007f/include
sudo mkdir -p /usr/local/imap-2007f/lib
sudo cp c-client/c-client.a /usr/local/imap-2007f/lib/libc-client.a

echo " "
echo "= FETCHING AND INSTALLING PCRE"
echo " "
cd "$BUILDDIR"
wget "http://sourceforge.net/projects/pcre/files/pcre/8.20/pcre-8.20.tar.gz"
rm -rf pcre-8.20
tar xvvfz pcre-8.20.tar.gz
cd pcre-8.20
./configure --prefix=/usr/local
make
sudo make install

echo " "
echo "= FETCHING AND INSTALLING PHP-IMAP"
echo " "
cd "$BUILDDIR"
PHPVERSION=`php --version|head -n1|cut -f 2 -d ' '`
##git clone -b "PHP-$PHPVERSION" https://github.com/php/php-src.git php-src
wget --no-check-certificate -c https://github.com/php/php-src/tarball/PHP-5.3.15 -O PHP-5.3.15.tar.gz
tar xvvfz PHP-5.3.15.tar.gz
cd `ls |grep php-php-src-|head -n1`
cd ext/imap
phpize
./configure --with-imap=/usr/local/imap-2007f --with-kerberos --with-imap-ssl
make
sudo cp modules/imap.so /usr/lib/php/extensions/no-debug-non-zts-20090626/

PHP on Mac no longer able to connect to MySQL

It’s been a while since I did web development on my Mac, and MySQL ceased to work. Could be related to that one time that I accidentally removed a bunch of dot-files from my home directory, could be related to MySQL upgrade. In any case, it no longer worked.
What I figured out was that the /var/mysql/mysql.sock UNIX domain socket was no longer generated. The /var/mysql folder was missing. When just creating it and assigning it to user _mysql (chown _mysql /var/mysql) did not help, I knew something was wrong with configuration.

MySQL tries to read configuration from /etc/my.cnf. To get its UNIX domain socket where PHP expects it, this needs to be contained in this configuration file:

[client]
port = 3306
socket = /var/mysql/mysql.sock


[mysqld]
port = 3306
basedir = /usr/local/mysql/
socket = /var/mysql/mysql.sock
; datadir = /servers/raiddrive/databases/

Please read the manual for details, and this is not administration advice; I’m not sure if this opens security holes, but I only use MySQL for development purposes. (Because you should know better than letting programmers near mission critical production servers.)

Yahoo! OpenID’s XRDS check, Apache2 and PHP

Another continuation of a previous blogging session :-)

A reminder, we’re talking about this:

Warning: This website has not confirmed its identity with Yahoo! and might be fraudulent. Do not share any personal information with this website unless you are certain it is legitimate.

PHP+Apache2 users out there might be interested in this reminder, which it’s already mentioned on previous post’s checklist, but I’d like to point it out again.

Don’t name your file xrds.xml.php and try to serve it as xrds.xml while changing Content-type to application/xrds+xml in the header. Apache2 is braindead (or used to be) and doesn’t even attempt to execute the file.

Yahoo! sends an Accept header in its HTTP request, listing application/xrds+xml. Apache decides your file is not of correct filetype, and sends Yahoo! the 406 Not Acceptable response. Referring to same file with the .php extension included makes Apache actually execute the file, and then compare the content-type to the accept header from the client.

Yahoo! and OpenID verification

Seen this in your OpenID consumer implementation when logging on to Yahoo?

Warning: This website has not confirmed its identity with Yahoo! and might be fraudulent. Do not share any personal information with this website unless you are certain it is legitimate.

Over there at http://zatemas.zrs.hr/ we’ve had this for quite some time now. How we eradicated it? Here’s a few pointers. I’m not sure what exactly helped.

  • More a generic tip than anything else: even Yahoo! crew recommends reading this blog post.
  • We had a redirect from our root page / to /run.php?app=news. We eliminated it through some trickery (setting $_GET and including run.php … sick but works)
  • Yahoo! discovers your XRDS document primarily through headers, just as aforementioned blog post says.
    • So on your realm page send header X-XRDS-Location pointing to your XRDS document.
    • And also include meta tags. ZATEMAS even added special kind of plugins so it can more easily send the special meta tag.
    • By the way, in janrain’s php-openid library’s openid consumer samples, the ‘realm’ is generated by getTrustRoot()
  • XRDS document should contain a pointer to your return-to page. (That’s the whole point.)
    • To stay on the safe side, I also added the aforementioned X-XRDS-Location header and meta tag into our openid_finish.php page.
  • Your XRDS document should return content-type application/xrds+xml
    • Apache looks braindead here. While it’ll happily serve our xrds.xml.php under xrds.xml, it’ll also happily refuse to serve it in case it gets “Accept: application/xrds+xml”, like Yahoo! does, resulting in 406
    • Yes, even with header(‘Content-type: application/xrds+xml’);
    • Point is: don’t avoid .php extension. All works if request goes to /xrds.xml.php instead of /xrds.xml — and you won’t see the problem or difference with regular browser. Only hint is when you open access logs and you see non-browser requests for your file ending up in 406.
  • Your realm page must not redirect.
    • Your realm page, your trust root. In ZATEMAS we use http://zatemas.zrs.hr/ – this means both production and SVN version (in subfolder /SVN) can consume same OpenIDs. Otherwise our users would get different OpenIDs from at least Google.
    • I’m not sure if it makes a difference to Yahoo!, but remember that forgetting slash in directory URLs means Apache performs a redirect. 
  • Again, don’t mess up: if you change filename, make sure you change both X-XRDS-Location header and meta tag.
  • Again, don’t forget: Apache won’t even open your PHP-generated XRDS document if only application/xrds+xml is accepted by the client, and you try to feed it by stripping PHP extension. Just keep the darned extension and serve it to the OpenID provider.

Hope my experiences help someone because this evening we finally got rid of Yahoo!’s warning.

One last note: if you’re a foreign visitor to ZATEMAS and you can’t speak Croatian, you can pass GET argument lang=en to make use of our automated Google-Translate-leeching string translation service. This only works in development version (subdirectory /SVN) because translation module is disabled on production site — it eats away too much page generation time :)

EDITED: This is value of Yahoo’s XRDS verifier Accept header: application/xrds+xml,text/html,text/plain