Baffling that this wasn't a day one feature. Doubly baffling that it now launches on Enterprise only with no guidance on if or when it will be generally available. Never an explanation why this couldn't have been there all along. You have it with the repos already. It almost seems like you would have to go out of your way not to have this baked in from day one. I'm a long term fan, but c'mon github, you're better than this.
I'm not that baffled, I guess. I would assume Github pages work something like "compile to HTML, push to a CDN" whereas Github itself queries a bunch of data from a database, reads the Git repo itself, etc. -- it's not a static page that can be served from a CDN, the page is generated by an application. Therefore, in the repo case it is easy to check authorization among the other things the page generation code does, whereas for static pages, there is currently no application code that runs for every request, and so no place to put an authorization check.
Obviously you could make the Github Page load a dynamic page that checks auth, but I guess they wanted scalability more than they wanted features, and that's what we arrived with.
TL;DR: I'm not that baffled. If a feature isn't in the spec, you shouldn't expect an implementation that makes it easy to add that feature.
I agree; you can easily have an authenticating proxy. Like I said, I'm guessing that they decided it was a static page on a public CDN first, so now it's hard to add an authenticating proxy on each CDN node. If they wanted auth from the start, then it wouldn't be a static page sitting on a CDN node, and it would be easy to add. (But harder to scale to a CDN, and thus we'd see a lot of Github Pages sites slashdotted or whatever.)
I could easily be completely wrong about this. But it's interesting, to me, to consider the order that features were requested, and how that affects future feature requests. Sometimes you paint yourself in a corner and make easy things hard. Something to think about as you plan your own software!
If you ask me, any page whose behavior depends on the currently logged-in user's identity, including the list of groups they're a member of, is not "static" in any meaningful sense.
Most people use "static" to mean that there is only one version of a response body. I guess denying access is technically a second version of the response body, but that's kind of a stretch because the layer where the body lives (ok, the two bodies: one for 200 and one for 403) doesn't need to be capable of business logic (like conditionals, db queries, etc.) during the request/response cycle. It uses them in perpetuity without tailoring them to the session.
