(post comments) GitHub hosted comments for GitHub hosted blogs

[izuzak]

This issue is reserved for comments on the blog post GitHub hosted comments for GitHub hosted blogs. Leave a comment below and it will show up on the blog post's Web page. Thanks!

[mojombo]

This is pretty great, I think I'll write it up on the GitHub blog!

[mislav]

Amazing!

Here's an issue for ya: justification on your article text! Scroll through your article again to see where it bites nastily

[izuzak]

Thanks, Tom and Mislav! I love that GitHub is so hackable that pulling this off was quite easy -- keep it up!

[izuzak]

Whoa... the new GitHub API (v3) is awesome! The Issues API directly supports fetching the HTML rendering of a comment's Markdown source so there's no need to do that rendering manually on the client side (using the Showdown lib)! I've updated the post to highlight this awesomeness :)

[bdesham]

Just as a heads-up, this seems to have broken at some point… each comment body only shows up as “undefined” when I read the blog post page.

[izuzak]

Thanks -- looks like it got broken as a result of a Comments v3 API bug, which I just reported http://support.github.com/discussions/api/365-comments-api-v3-broken-not-returning-comment-bodies.

[ppanyukov]

This is great. I only wish it was possible to leave anonymous comments too... Requiring github account is waaay too geeky for most people out there (admit it, we are a minority here).

[Pyrolistical]

I really like this idea but can we take it to the next level? Would it be possible to render a comment form at the end of the page along with a captcha? Would it be possible to have a captcha web service that makes the submit comment on your behalf? This way you can still keep your blog as a client side app with no backend. It would be all that hard to write such a web service and host it on cloud foundry.

[izuzak]

@Pyrolistical -- that's a cool ided! And you're right, it wouldn't be hard to write such a web service. However, that still introduces another component into the picture which someone has to maintain, because if it goes down - "no commenting for you"! Also, you could still bypass the captcha by going directly to the github issues page and commenting there.

In general, I tend to think that captchas are not needed because the commenting system is tied to GitHub and only GitHub account holders can comment. Therefore, if someone starts spamming GitHub issue pages - you can be sure that the GitHub crew will do a much better job of chasing such accounts down and stopping them than any captcha system.

[izuzak]

@ppanyukov Sorry for not answering before. You're right -- anonymous comments would be cool. But using OpenID to login into GitHub would be even cooler. Until then, people will just have to learn to love GitHub :)

[visconte]

Hi @izuzak! I've played around with your pretty cool commenting system. I changed it to get HTML from issue tracker. The only thing unclear for me: does my hack work with some versions of Chrome. Please look at _layouts/post-old.html from my repository visconte.github.com. You need in addition the following files:

• css/comments-old.css --- extracted part of your CSS for comments, I made it a bit shorter.
• /javascript/jquery.xdomainajax.js from there provides cross-domain AJAX.
• /images/modules/comments/metabar.gif --- just a copy from GitHub.

I don't intend to keep these files always, so don't forget to copy files you need. I think the further step for commenting system is to make a commenting form on post's page. For instanse, preview can be done with GFM JavaScript (maybe the preview is not necessary). After comment is sent, it can be edit from post's page using a JSON request. However, this requires user authentication on post's page. Yes, GitHub allows to do this task as well, but I see huge code size should be made.

[izuzak]

Hi @visconte! :) That's very cool, thanks for finding the time to work on that and write up a comment! It took me a while to understand what you actually mean by "get HTML from issue tracker" i.e. that you mean directly getting the comments in HTML format without calling the showdown markdown converter.

As it turns out, your solution only partially solves the problem. Furthermore, the "jquery.xdomainajax.js" you are using is useless as it is not being used at all when you make your $.ajax request. However, your comment made me look at the GitHub API documentation again, and what I found there is something I've been waiting for for a long time and which solves the problem of fetching HTML comments completely. Let me explain these things step by step.

First, why was there a problem with fetching issue comments in HTML?

The GitHub API does enable setting the desired mime type (e.g. application/vnd.github.VERSION.html+json for HTML), but only through HTTP headers. In a browser, you can set HTTP headers only for XmlHttpRequests, which are subject to the same origin policy. Because XmlHttpRequests are subject to the same origin policy, you can either make these requests to server resources on the same domain (e.g. you can make a request from visconte.github.com/test1 to visconte.github.com/test2, but you can't make a request to foo.github.com), or to server resources on other domains if they use the CORS specification which lets you make cross-domain requests. Until recently, the GitHub API didn't support CORS, so I've had to use JSONP to communicate with the GitHub API. However, JSONP doesn't enable you to define the HTTP headers in order to specify the Accept header, which consequently doesn't enable me to directly fetch the HTML version of comments.

Second, why does your solution work?

The jquery.xdomainajax.js library which you included gets around the same origin policy by using a proxy component, and in this case - the proxy is a Yahoo YQL server. Using that proxy, the script can make cross-origin calls. However, if you look more closely at the HTTP requests sent by the browser when fetching comments for your blog, you will see that the script is not being used at all! Rather, the GitHub API is contacted directly and the it returns the comments as you expected. Here are the reqest and response sent by the browser when visiting your blog:

Request

GET /repos/visconte/visconte.github.com/issues/1/comments HTTP/1.1
Host: api.github.com
Connection: keep-alive
Origin: http://visconte.github.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.8 (KHTML, like Gecko) Chrome/17.0.934.0 Safari/535.8
Accept: application/vnd.github.html+json
Referer: http://visconte.github.com/2011/08/14/github-hosted-comments-for-github-pages.html
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8,hr;q=0.6
Accept-Charset: windows-1250,utf-8;q=0.7,*;q=0.3

Response

HTTP/1.1 200 OK
Server: nginx/1.0.4
Date: Fri, 11 Nov 2011 10:15:55 GMT
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Status: 200 OK
X-RateLimit-Limit: 5000
ETag: "115ddd57cbaaf75b5cfa7c9c385afd88"
Access-Control-Expose-Headers: Link, X-RateLimit-Limit, X-RateLimit-Remaining, X-OAuth-Scopes, X-Accepted-OAuth-Scopes
Access-Control-Allow-Origin: http://visconte.github.com
X-RateLimit-Remaining: 4995
Access-Control-Allow-Credentials: true
Content-Encoding: gzip

Notice the Origin header in the request and the Access-Control-Allow-Origin in the response. The Origin header specifies the domain from which the request originated, while the Access-Control-Allow-Origin specifies the domain which is allowed by the server to make the request. Notice that these two are the same in your case. Therefore, your solution is working because GitHub has recently enabeled CORS in such a way that the API enables GitHub sub-domains to access the GitHub API. In other words, if you make a call to api.github.com from visconte.github.com, that request succeeds because GitHub has enabeled CORS for XmlHttpRequest and for *.github.com subdomain, and for no other reason. Edit: this turns out NOT to be true. GitHub does NOT enable CORS for *.github.com by default. You have to add each CORS supported domain as an OAuth application. See comments below for an explanation.

Third, and most important, why is your solution not general enough?

Your solution works because your blog is hosted on a github subdomain (visconte.github.com). However, this is not the case for my blog which is hosted on ivanzuzak.info. Therefore, until 20 minutes ago, if you made a request to api.github.com from my blog ivanzuzak.info, that request would fail because GitHub API CORS enables request only from *.github.com. In other words, any blog with a custom domain cannot use your approach and needs something else.

How did I solve the problem? Well, notice that the GitHub API documentation on CORS says that you can extend the list of domains which the GitHub CORS allows for cross-origin requests, by registering your site as an OAuth application. Therefore, everything that needs to be done for sites that use custom domains is to register the site as an OAuth application for using the API. This is what I've done and now I can make cross origin request from ivanzuzak.info to api.github.com!

I'll update my blog post to include a more detailed description of this process. Let me know if this wasn't clear enough :).

Also -- your solution has nothing to do with browsers (or at least - it shouldn't). It should either work in all browsers, or not work in any browser.

[visconte]

Thank you for the answer! You are right, jquery.xdomainajax.js is not necessary. Are you sure that GitHub has recently enabeled CORS in such a way that the API enables GitHub sub-domains to access the GitHub API? In fact, I also registered my blog as OAuth application, and as I remember then my solution started working in a while. So the registration is needed in any way. Sorry, I didn't pay attention to this fact in my previous comment.

[izuzak]

Ah, you're right and I was wrong! Thanks! GitHub doesn't enable CORS by default for *.github.com domains. I assumed it did because it worked for your site and I assumed you didn't register your site as an OAuth application. (I'll edit my comment to reflect this).

I guess we both came to the same conclusion, after all :)

[hit9]

Have a test!