Feedback on my PHP GitHub Webhook script

Hey guys, so I would like some feedback on this webhook I was working on yesterday. Pretty much, it’s supposed to allow you to use your Github repo as a version control for your actual website. What that means is, you can use your Github repo to update your website. You have to add the deploy.php file to your repo settings. Once you update a file within your Github repo, it’ll also download that updated file to the destination path you’ve specified. Pretty much, you can roll back a file using Github or you can update a file using Github. I didn’t add in the removed commits because I didn’t feel like deleting actual files was a safe thing to do. So if you want to see that kind of thing, let me know and I’ll see if I can put that into this webhook.

But yeah, the sample code to initiate it is on the repo as well. So let me know what you guys think. Make sure to do it on a sample folder because I don’t want you guys overwriting anything on your websites. I’ll also try to make a video tutorial on what it’s supposed to look like and what it’s supposed to be doing later on today.

5 Likes

Thanks for the sharing and for a great tutorial!

And my noob question about using a private repo was also explained in the end. :blush:

1 Like

Thanks. I feel like there could be improvements so any feedback (even negative) will be much appreciated.

I like the idea and only concerned about showing sensitive information about Mysql user names and passwords. If this information was saved to a file above the server root would the file still show in the Github Repo?

May I suggest creating a free website and having a live demo?

[off topic]
Freenom.com is a service that I have used for a long time, They offer free twelve month renewable domain names and also cheap domain registration.
[/off topic]

I hope to give your Repo a try when I have cleared my desktop…

1 Like

Good question. My take was the username and password would be there only when the repo was private, and that as long as only the owner had access to the private repo, or, if the repo wasn’t private and the username and password were not included by mistake, the only risk would be forgetting about it and making a private repo public.

3 Likes

My initial thought was also that. I didn’t want the passwords to be plain text because obviously anyone can read what the passwords are. My first thought was to use password_hash(), but then it wouldn’t make sense. There’s no other first password to compare it to. Since the 2nd argument has to be the hashed password, it makes no sense to use password_hash(). That was the difficult part, but I did take both your advice and I’ll probably make a note or a modification like I did in the video below so that the passwords are in a different file above the root folder. It’s a bit late so I won’t be doing any code modifications at the moment. I’ll most likely do that tomorrow when I get home from work.

Sure, here’s a short demo on what it’s supposed to do. I’ll go through what is going on in the video since there’s no audio because I tend to not record in audio.

So first 15 seconds, all I just did was demonstrate what I currently have written down to initialize it. Then I used Gitkraken to create my private repo. Just a little note, it really depends on your preference which ever way you choose to create and modify your repo. You can use Gitkraken to create, modify, and delete files or you can use the command line to do that as well. You can even do it via the website as well. It’s really up to you. I’m just demonstrating 1 way to do it.

Do take note of the sidebars where the filenames are. Take note on how many files there are and what the filenames are called. You’ll see what happens near the end of the video.

So further in the video, all I just really do is go through the steps that are on the Github repo. It’s pretty much the same exact steps. You just go to the settings of the Github repo and you add in the full URL to the Payload URL text box. That’s pretty much it. Then hit the green Add webhook button. Once you do that, you should get a green checkmark right next to the URL link. If you get a red circle, that means something went wrong. I demonstrated what you should be seeing when you first initiate the ping. You should get a 200 message saying “Successful ping”. If you don’t and there’s nothing in the body of that 2nd tab where the 200 message is supposed to be shown, that most likely means that you have an error on your script. Check to make sure everything is used correctly. If you happen to get a 404 error, that most likely means that you are trying to ping a site that isn’t yours. I took precautions and actually added the repo option just last night. The repo option checks to see which Github repo is triggering the URL. If the repo’s name is not in the whitelist in the repo option, then it’ll reject everything and give you a 404 error. I took safety measures to make sure people aren’t attempting to modify other people’s websites using unrecognizable repo payloads.

Next, I demonstrate what this entire webhook is supposed to do by creating a file called test.php locally on my Mac. Then I pushed that file to Github using Gitkraken. Once I pushed that file, the Github webhook instantly gets triggered and actually downloads (not really, more like just copying the contents within that file and making a copy in the destination that’s specified) that file onto my server. You can now check the sidebar on the left. You will now see a test.php file where before, it wasn’t there. I then checked that file to see it’s content. The content was exactly the same content I had written in the local version which I then pushed it to Github.

What I also forgot to show was the payload for the test.php file. Well not the actual payload, but the returned JSON result.


So in the next update, I’ll probably make some small modifications. I remember seeing a private object in the repository object class. So I’ll most likely put that in the next modification. What I intend to do with this option is instead of giving the user a blank file if it’s a private repo, I was just going to return a JSON string back to the user saying that the repo is private and that they need to either put in the username and password to get the webhook to work or set the repo to public. I’m also going to add that password thing in the next modification as well.

2 Likes

Alright. So I did minor tweaking and I made a few changes to the README.md file. For the deploy.php file, I basically added a few things to it.

  • Made sure that you actually have file permission to create and modify files on your server. *
  • 404 error response if you are running private repos without the additional Github username and password.
  • Changed the response to take in regular arrays instead of stdClass objects. **

* - Basically I should of done this in the initial code, but I apparently didn’t do this. When you don’t have read-write-execute permissions on a folder, you’ll end up getting a broken JSON response. If you looked at the raw headers, you’ll find PHP errors saying Permission denied. I apparently forgot to check for this in the initial code. Basically, you can’t create, update, or do anything in that folder if you don’t have those 3 permissions. So I finally just added that in there.

** - Another mistake that I made. I thought it would be “cool” to encode everything in stdClass objects. But yesterday morning, I realized that you can’t run filenames with periods or any special characters in there when you are trying to reference the indexes. For example, this won’t work.

$deploy->test.php

You cannot do that in PHP because the . will “assume” you are concatenating. So I decided to turn all of these responses to regular arrays so that you can reference the response as so

$deploy[0] == 'test.php';

Last, but not least, I am looking into maybe doing the removed commit part. Still working on it as we speak (or write).

Let me know if anyone of you guys feel like this needs more work. Would like to get some inputs/ feedbacks so I know what to put in there and what not to. All feedbacks are appreciated.

1 Like

This topic was automatically closed after 91 days. New replies are no longer allowed.