SOAP headers and PHP 5.2.3

My last post about how to handle SOAP headers was done with PHP 5.3.5-1ubuntu7.7 with Suhosin-Patch (cli) (built: Feb 11 2012 06:22:51).

I tried to run the same installation on PHP 5.2.3 and it failed to handle SOAP headers.
Documentation on is a bit lacking of details about this. Even after an extended search with friend google, I’m still not sure if it is some flaw in the installation or if PHP 5.2.3 simply cannot yet handle the SOAP headers.

But well, there is always a (dirty) hack and at least this one points a way out if you might be stuck using older PHP versions. And I learned a lot about DOM document as well ๐Ÿ˜€

So what we can do in this case, is to extend the PHP SoapServer class and add our own handling function. The standard SoapServer::handle function is usually called without any arguments. In this case it is assumed, that the SOAP request data can be found in $HTTP_RAW_POST_DATA (php.ini setting always_populate_raw_post_data must be set to true for this) or by reading php://input.
So what we do is init a SOAP client and set the SOAP object in our own handling function

For this we simply extend class SoapServer with out own class, grab the request data before calling handle, parse request for authHeader, make a new SOAP object and use the extracted info for user authentication or whatever we want to do before the real handle starts (call to hrapp_soap_soapclass::checkParams). Then we set the SOAP object to SOAP server and handle the request.

By doing so we could even completely change the request or decide on the fly about using a completely different soap object class etc… Think about other uses of an extended SoapServer class, not only for forcing SOAP header handling on PHP ๐Ÿ˜‰

Here’s the code:

SOAP request with a SOAP header

SOAP request with a SOAP header

SOAP server

SOAP server

SOAP server, header parser

SOAP server, header parser

SOAP class

SOAP class

Posted in howto, PHP, SOAP | Leave a comment

My own little SOAP


  • Some WSDL file.
  • Some endpoint that either coughs up the wsdl or let’s the SOAP server handle a request.
  • An object that does the SOAP handling (use SOAPServer::setObject)
  • A SoapClient to see what happens when the SOAP server is called
  • A I love to use unit tests for spike solutions: a unit test

Goal: get a little SOAP service up and running and see what we can use SOAP headers for.

Point is: if the SOAP client send a SOAP header with a fixed name, you need a function with the SOAP header’s name in the class you use as SOAP server object.

If the header processing function exists and the header is sent, SoapServer::handle()
calls first the header processing function and then the requested SOAP function.

This means you can user the header e.g. for user authentication or setting some locale id etc. without having to change the wsdl. Good for backward compatibility.

Here’s the code:

the WSDL structure

the SOAP object class

SOAP server initialization

Spike by unit test part 1

Spike by unit test part 2

Note: I did this example here with PHP 5.3.5-1ubuntu7.7 with Suhosin-Patch (cli) (built: Feb 11 2012 06:22:51).

Posted in howto, PHP, SOAP | Tagged , , , | Leave a comment

Book: Online Shops with OXID eShop

Finally decided to get my hands on one ‘the book’ about OXID eShop.
According to the description, this book is meant for newbies wanting to have a first look into what you can do with OXID eShop. And as I’ve been doing some pet projects with the community edition, I wanted to have a look.

It is a nice book to have a first peek into what you can do with OXID eShop Community Edition, but it is in no way a book for developers (which I knew before and did not expect).
So as soon as it gets more complex than the basic installation, you need to refer to other sources. In case you need to dig deeper into code, templates, modules etc. ask friend google for useful links or try to find help from the OXID community.

On the other hand: that’s exactly the book you need if want a shop up and running without having to bother with the code behind it ๐Ÿ˜‰ But you should have at least some rudimentary idea about what a web application does.

Did you expect me to not start giving my2Cents? Forget it, here’s some comments on certain chapters and you probably need the book in hand to understand what I mean:

Chapter 2 – Installation

I did a lot of installations of OXID eShop over time on different local machines and also on my low budget no db views allowed shared hosting server. Worked fine all the time (Windows XP, Vista, Linux) but when finally switching to Mac, I decided to no longer install directly on my machine but on a virtual machine inside my host computer. If the server installation is screwed up, you just can go back to the latest snapshop and start from there. If your host machine gives up, just move the virtual machine to the next host.

So for a test installation, xampp is really great if you are unexperienced and only interested in running the shop, if you need more (here goes developers) better set up a virtual machine and start from there.

Chapter 12 – OXID eFire

In my opinion the authors could have spent some more time on explaining what OXID eFire can do, this chapter is way to short to explain all possibilities. After all, this service is also an important part of the OXID Biosphere. Just look at the eFire start page to have a peek into what’s possible.

Btw: For security reasons you should NOT use the same login credentials for logging in to eFire GUI and for letting your shop access eFire SOAP service.

Oh well … with as example they picked the only ‘Portlet’ that still is enabled via Mail request directly to OXID. Usually portlets are enabled by a so called registration workflow (kind of an n-step wizard guiding an explaining you through the installation).

Chapter 15 – Maintaining the shop

Did I complain about the short chapter about eFire? They should also have spent more time on extensions and modules. But well, ok, maybe that’s also a topic for a developer book.

To the authors: I did not count how many sentences start with ‘Last, but not least…’ but there’s a lot ๐Ÿ˜‰

Posted in books, oxshop | Tagged , , , , , | Leave a comment


…just signed up for news on about

iPhone, mobile e-commerce, open source, all the buzz words I LOVE to hear.
Let’s see what’s behind this.

Posted in oxshop | Tagged , , , | Leave a comment

Howto make your live easier with an autoloader

Do you honestly want to include all needed classes at the top of every one of your php files? If you say yes, go on, have fun with your code, your problem.

Ok, so an autoloader cares about loading all classes needed in your php code. You do not need toย  explicitly include them on top of every file, but if you call new myclass, the autoloader takes care about finding the class file. With spl_autoload_register PHP gives you the possibility to register a whole stack of autoloaders. So for example you start with your own autoloader then you might have an external library that needs another autoloader etc.

Example: Project with the following structure:

project structure

project structure

Folder hr is for the projects’s own classes that should lie outside of doc root. Folder hrtest contains the tests for classes in folder hr. Library is for storing external libraries like hereย  Zend Framework and phpunit.

When using an autoloader, you need a naming style for classes. For example calling new hr_cache_file makes the autoloader search for hr/cache/file.php and include it if the file can be found.

class naming convention

naming convention and file structure

Here’s the autoloader code:

autoloader structure

autoloader structure

autoloader function in detail

autoloader function in detail

Now include in your entry point like index.php and call new classname without thinking about explicitly including files.

Short note: The include path is set on the fly at runtime here as I will use the same vhost for other small test projects as well. I’m too lazy to configure it properly right now.

Posted in howto, PHP, tools | Tagged , | Leave a comment