IIS and those pesky Flash files

Doesn’t it drive you mad when you set up an IIS server in Windows and you forget to add Flash files to the MIME types? You end up debugging what you think is some scripting problem only to remember about 2 hours later that IIS’s file support out-of-the box leaves a lot to be desired.

Well, I can’t stop you or me not wasting time, but I thought that I’d collect up file types here for reference:

Flash
Extension: .flv
Content type: video/x-flv

7-zip
Extension: .7z
Content type: application/x-7z-compressed

WIM – Windows Image File
Extension: wim
Content type: application/octet-stream

ASpell, PHP and IIS

I’ve been trying to introduce spell checking into my PHP application and have been hitting a small snag. It’s called ASPELL.

For the uninitiated, aspell is a command-line spelling utility to, well, do clever spelling stuff.

In Apache, aspell works wonderfully. In fact, I wouldn’t have even thought that there was a problem. IIS on the other hand has different issues.

It’s easy to ask why I’m running my application on both servers, so I’ll quickly explain that one.

When I’m developing, I use Apache. For me this is an internal facing server which facilitates my needs of having simple-to-use easily editable configurations.

IIS faces the rest of the world because it hosts my email server (Exchange), so I don’t really have a choice about what I have on port 80.

Because of this, I always run demos on port 80 as a lot of sites I work in only have port 80 available, so IIS the the chap.

Anyway, the bottom line is that when aspell wants to run in IIS, you’ll end up with something like the following error on the client browser:

System error: Aspell progrem execution failed ('aspell -a --lang=en_US < C:WINDOWSTEMPasp1FB.tmp 2>&1')
Catchy, eh?

The problem is that the Windows security model is not allowing PHP to use the shell_exec() interface. And quite rightly, too.

To work around this, you must set permissions for cmd.exe in %windir%\system32 to allow your website visitors to run these external applications.

NOTE Allowing this means that website visitors can theoretically upload scripts that can execute commands on your system. Be very very careful that you are the only person able to upload scripts. Take all other web-security precautions.

A good idea would be to create a dummy user account solely for the website you have created, and give that user minimal permissions on the server.

Finally, don’t blame me if your system gets hacked!