Samuel Henderson and I are using Google Code for a project we're doing for a university class. Anyway, we're planning to use Doxygen to document the code and thought it would be great if we could have the up-to-date documentation automatically published on the Web.

In the administration section for Google Code, there is a text field for a post-commit URL. This sounds like just what we need, but I'm having trouble understanding what the request will look like so I can process it.

The request is described as an HTTP POST request, and in How to use Post-Commit Web Hooks for your project, they describe the request "payload" (what is an HTTP POST payload?) as describing the commit using the Web Hooks model, consisting of a UTF8-encoded JSON "dictionary".

I was hoping to use PHP for the post-commit hook because I already know enough about it to be comfortable and I expect "the Web host" has PHP installed (they did in the past anyway). I expected to just write a Web-based PHP script that would make some (ugh) exec (or similar) calls to update a working copy, generate up-to-date documentation with Doxygen, and copy the up-to-date documentation to a Web path.

I just don't understand what the request will look like. Specifically, the payload/JSON parts... And I don't want to test it out with a bunch of meaningless commits when I don't even know what I'm getting...

Is anybody familiar with Web hooks and what I should expect? Can I use a PHP script with a typical Web server (Apache) to process it? Is the JSON going to be accessible to PHP if I do...?

I can't seem to find an appropriate channel to ask Google Code themselves and it seems nobody else is having this problem because my searches have come up empty...

The payload is basically the same as a form post I would think. And PHP 5.2 at least has JSON support by default (maybe it was 5.1 that had it) but you can find libraries for JSON anyway.

The Google page you posted does show what the JSON may look like. Sadly, I never heard of Web Hooks, so I'm not sure where you would read the data from, and the wiki doesn't seem to help at all.

[edit] If I'm reading the Python code correctly, then the data should be coming in $_POST['body'] for the JSON string. But seeing as I never bother to learn AppEngine and have no web page related knowledge with Python, that is only a guess on my part. It seems Web Hooks is just an idea really, like the Model View Controller (MVC) model.

I guess it won't hurt to try... I can log whatever I do get to a file and see what I have, I suppose... Hopefully nothing explodes as a result.

** EDIT **

I have written a simple PHP script that logs everything in the $_REQUEST superglobal (i.e., the contents of $_GET, $_POST, and $_COOKIE) to a file. When I supplied Google Code with the URL there was initially nothing. I figured my PHP was wrong because I thought Google Code was definitely supposed to send the project name and revision as GET data, but then I realized that I had to include %p and %r placeholders in my URL for Google to send that. Once I made the necessary changes to my URL, those variables were logged and nothing else. So that JSON must be somewhere else... Any ideas?

You will need to set always_populate_raw_post_data to true with ini_set, then read from php://input to get the raw post data. That's where the JSON will be I believe. $_REQUEST won't work because it's not encoded form data.

That sounds like something. Do you have a link that might explain that a little further?

Look up ini_set to learn how to use that. Then open php://input like any other file and read from it.

Are you sure I need to set always_populate_raw_post_data to true?

- Source

** EDIT **

Well I seemingly read from php://input, but what I read was nothing... Oddly, even the GET data that is supposed to be logged before the php://input is no longer in the file... I'm not sure what is happening. I haven't yet set always_populate_raw_post_data to true, which could explain why that isn't working... But why is the GET data gone?

I don't know, I just read something about php://input and HTTP_RAW_POST_DATA not being populated for unrecognized MIME types.

The docs seem to say it doesn't work for multipart/form-data forms, which seems silly. How does php handle forms with file upload items?

It does so internally, it just doesn't allow you to access the raw data in that case.

As expected, I don't seem to have permissions to change that setting.

Maybe it's in $_FILES?

I figured I would forget about the JSON data for now and just attempt to get my hook script working as intended (updating doxygen html documentation and moving it into a public location). Unfortunately, it occurred to me that without read/write access, the script is unable to do anything on disk... Which means it can't even do its job. I don't think there's any 'secure' way to do it ATM. I could give certain files read/write permissions for everyone, but then anybody with access to the server could stumble upon it and do something malicious... So I basically can't do anything, except for maybe talk to the administrator to see if they can get my script running in a specialized user account. Then I could create a special working copy for my Web scripts and give just that account full permissions on the necessary files... Without that, I don't think I have any options... And I REALLY doubt they would go to that trouble on account of a graduate... Last I heard, the server was being administered by the IT department and they weren't happy about it (it used to have a dedicated administrator).

CGI scripts should run as your user. Suck it up and use a different language for what seems to be trivial commit processing.

Anyway, if you do permissions right and the web host is set up right, it should be mostly secure anyhow. The files should be owned by group apache (or a group apache runs under), with RW access given to group (not global though). CGI scripts would be running as the owner, so they shouldn't be able to access. PHP runs as apache if you're using the module (at least last I knew), but if that is secured (with open_basedir and such) then it should be fine. Not counting loopholes/exploits, and if your data is so valuable that obscure exploits are a security liability, you wouldn't be on shared hosting anyway.

I don't know how to use CGI scripts... I assume the server has to be configured specially for that (which I assume it isn't...)? I'll look into it though, thanks.

I already tried to find out what user the PHP script was running as by executing print(getenv('USER'));, but nothing came out. And even if I did use a Web server specific user or group, that still opens it up for any malicious student to write a PHP script and access it over the Web...

Are you on a Windows box? To get the user, use get_current_user() if you're running Windows, otherwise, posix_getpwuid(posix_geteuid())['name'] (syntax don't work I believe for PHP, but you get the point)

I'm doing this from a Linux box. get_current_user didn't work either (I guess cause it's Linux). I'll try the POSIX version when I get a chance.

You can look at some of the a5 code that fetches the user and its home dir.

I take it back! \o/ Apparently our old administrator enabled CGI when he was here and it hasn't been changed! I just wrote my first CGI program, hello_world, in C!