Oh xdebug, where art thou?

I don’t have a stable development environment. I change hardware and software frequently so whenever my wife’s web site needs a revision I usually have to set everything up from scratch. I always develop on a Linux box (I am a Fedora user) and I’ll usually set up an apache server with MySQL running. For development I prefer NetBeans but I’ll use Eclipse if I have to.
For debugging I use XDebug and this is where the fun starts…

It never seems to be a smooth ride getting XDebug up and running, no matter what I do and judging from the many desperate cries for help on various forum threads I am not alone.

This blog post will not solve all your problems with getting xdebug working but I hope it might help you and give you a better set of tools to solve the problem.

The “problem” here manifests itself in NetBeans or Eclipse failing to connect to the debugger.

Firstly, if you have installed xdebug using any of the normal methods and phpinfo() shows an xdebug section then, at least in my experience, you’re good to go and any amount of hacks and fiddling in ini files is unlikely to fix your problem.
It is much more likely then that the problem is external and here is my simple check list of culprits that always seem to be behind my woes, either individually or together;

  • is your firewall allowing port 9000? (the default xdebug port, yours might be different but try not to fiddle with it too much)
  • is SELinux blocking you?

Run your firewall tool of choice (I just run system-config-firewall on Fedora) and check, or add, port 9000. Now try again…if working be happy, else…
Check if SELinux is barking about blocking a “name_connect” and see if port 9000 isn’t mentioned as well. If it is then you need to allow connections, obviously, and since I am not running my Linux box in an environment where I need to be too concerned about paranoid security I just blanket allow httpd (the apache server service I’m running on Fedora) to do whatever it wants;

#setsebool -P httpd_can_network_connect 1

If that doesn’t fix it then I sympathise because nothing is quite as frustrating as struggling with tools when all you want is to get the job done. But, in my humble experience at least, it seems to always end up being something like the above, I.e. something external is blocking xdebug from working. My point is that, unless you have a very peculiar set up, a plain vanilla install of xdebug with the standard ini file entries is fine and you should avoid fiddling with it before you’ve checked the external conditions – even though forum threads out there are quick to suggest it.

Good luck and happy debugging!

Advertisements

Basic LDAP support in phpBB on a corporate network

I love phpBB and wanted to use it on our intranet to facilitate knowledge sharing between departments.

Getting phpBB up and running on a spare PC (powered by xampp) was easy but to make it useful in a corporate environment you need to be able to use active directory log-ins, and that wasn’t quite as easy, at least not for me who had no previous LDAP experience.

One thing I need to point out before you get your hopes up too much is that – at the time of writing – the LDAP support in phpBB 3 is fairly basic; you can log in but no new accounts will be created in AD and AD groups can’t be mapped to phpBB groups. The latter is a real issue for me since we want to use AD groups to manage access and without that we need to do a lot of manual admin on the phpBB side. However, as a first step to integrating phpBB in your corporate network this will do the trick.

But without further ado, this is what I did to make it work;

Firstly, you need an LDAP Service Account. This is an account that you probably need to ask your local neighbourhood IT department to set up (I did anyway). It’s a special account that will be used as a proxy to validate the credentials of users. They should know what it is….

Let’s say, for simplicity, that this account’s details are as follows;
username: phpbb_ldap_service
password: pa55w0rd
email: php_ldap_service@company.domain.com

We also need the details of our LDAP server and in this article we’ll take those to be
hq-ldap.company.domain.com
serving LDAP requests through port 368

I will now assume that you have set up phpBB and have it running. You will also have enabled the LDAP module. I was running this on xampp under windows and had to;
– Enable LDAP in php.ini (uncomment the ldap extension load)
– Copy libasl.dll from xampp/php folder to xampp/apache/bin folder and restart server

At this point I set up my forum to not require any admin approval for new users and I also set it up so that new users could start posting immediately; I trust my colleagues…

Furthermore I registered a new user in phpBB with the exact details of the service account, i.e;
username: phpbb_ldap_service@company.domain.com
password: pa55w0rd

This is very important! The phpBB account must match the service account for all of this to work.

NOTE: I’ve used the email address here, not the user name. This is because I want to let users log in using their unique email addresses later. You can choose this (as you will see below) and this was a requirement for me; your preferences might vary.

Now log in as a forum admin and give our service account user admin rights too. This too is very important!

Now log in using the service account that you’ve just granted admin rights and go to the “Authorization” pane where you will set up phpBB to use LDAP and connect to the server for authentication.

Set it up as follows:

Authentication method: ldap
LDAP server name: hq-ldap.company.domain.com
LDAP server port: 368
LDAP base DN: DC=company,DC=domain,DC=com
LDAP uid: see below for how to populate this
LDAP user DN: ditto, more about this below
LDAP Password=pa55w0rd

(Fields not mentioned above can be left blank or default)

The LDAP uid field is where you specify which field in an AD record for people in your corporate network should be matched against for authorisation. I am not an LDAP expert so I don’t know for certain if these are “standard” but what you will find if you google it is that most people use “samaccountname” which maps to the user name. I.e. for Joe Bloggs to log in he would use his network user name which, for example, would be jbloggs.
However, I wanted to use the email address and not the log in name so I had to dig around in our AD directories to find out what field was used to store that. Again, this might be a standard LDAP thing but I am not sure so check with your IT people or use an LDAP tool to look at accounts. In my case the field I chose for LDAP uid was “userprincipalname” which was where the user’s email address was mapped to in our AD setup.

The user DN is a string which identifies the service account in your AD structure. It is sort of like a path name for the account and quite frankly the many examples I could find when I googled it confused matters more than anything so I recommend you either determine it using an LDAP tool or, again, just ask somebody in your IT department….

Once those fields are filled in and correct you hit submit and phpBB should present you with a nice green message box telling you that all is well….

Subsequently you can log in with your email and network password, simple!

What could go wrong?
Lots of things, and the lack of helpful error messages from phpBB makes it a frustrating task to determine root cause.
What I would say though is that, if it doesn’t work, then you should firstly go back and check that you’ve got the right server, port, user DN, service account, password…all of those things because it is easy to trip them up.
Get an LDAP tool like Apache’s Active Directory Eclipse plug in and test your assumptions (is that user DN really the right path to my service account?)

It took me about half a day from start to finish which doesn’t sound like much but I can assure you that it was a frustrating couple of hours…I hope you experience is less painful!

Good luck!

A tip about tweeting from a PHP app using OAuth

I followed this excellent tutorial by Adam Green;

http://140dev.com/twitter-api-programming-tutorials/hello-twitter-oauth-php

but for the life of me I couldn’t get it to work; I kept getting a 401 return code saying that my app did not have write access.
But, I had given it write access so…what happened!?

Actually, the cause and effect, and subsequent fix, was simple but not entirely obvious;
I had created the app as a READ ONLY app to start with and generated all the codes for it.
I then had realised my mistake and set the app permissions to Read & Write. The dev.twitter.com page for my subsequently showed me that me that the app now had the required access.
Still, I got a 401 error back.

I had not, however, recreated my access tokens (there’s a button for this at the bottom of the page.)
Once I did this the app worked.

So; the confusingly named “Access Token” and “Access Token Secret” need to be regenerated if you change the permissions for your app. This is not obvious to me since I would expect these tokens to encode the identiy of the app and therefore allow Twitter to access its permissions through the back-end…
But there you go, at least now it works.

Zend tip: disable all rendering in controller when serving AJAX request

NOTE: this assumes you already know a fair bit about how the Zend framework’s rendering and layout engine works.

I have a Zend Framework powered web site that I’m adding some AJAX to. Serving the AJAX request inside a controller by looking for requests with the isXmlHttpRequest flag set to TRUE is simple.
Inside the controller you then assemble whatever JSON or HTML response you have and return it, like this for example:

$this->getResponse()->setHeader('Content-Type', 'text/html')->setBody($response);

Ok, the point here is that when I did this and dutifully called setNoRender using the viewRender helper, my clean and simple response had a large chunk of HTML appended to it.
Now, I am using “response segments” in my Zend layout, i.e. I’ve got a controller action that automatically renders a part of every page, regardless of which controller is the active one. It was this controller’s rendered output that – still – was generated and appended to my neat AJAX response.

So, it turns out, that to prevent this to be rendered I had to disable all controller rendering and setNoRender doesn’t do that. It just disables rendering from within the current controller.
The code to include is instead
$viewRenderer->setNeverRender(true)

This works, and it is auto reset every time you reload the page.

Now my AJAX response is just what it should be.