[REQUEST] Configurable filepath and other Jekyll-isms

[JustinAiken]

If using jekyll as described in gitlab's pages/SSL tutorial, public is a directory built from running jekyll build, so the challenge file would need to be committed somewhere else.

So if filepath instead of being hardcoded to public/.well-known/acme-challenge/${key}, was something like ${options.root_path}/${key}, this could work for various blog generators too..

[JustinAiken]

Actually, to make this work with jekyll, here's the full changes I had to hardcode:

46c64
<         return Promise.resolve(gitlabRequest.post({
---
>         return Promise.resolve(gitlabRequest.put({
49c67
<                 file_path: `public/.well-known/acme-challenge/${key}`,
---
>                 file_path: `letsencrypt.html`,
52c70
<                 content: value
---
>                 content: `---\nlayout: null\npermalink: /.well-known/acme-challenge/${key}/\n---\n\n` + value
54c72
<         })).return([`http://${domain}/.well-known/acme-challenge/${key}`, value]);
---
>         })).return([`http://${domain}/.well-known/acme-challenge/${key}/`, value]);

• put instead of post, since I already had an old challenge file existing - needed to update instead of create
• filepath had to change to a file that generates the file in public/, instead of that file itself
• content changed to generate jekyll front-matter along with the response
• Trailing / added to the challenge URL (pretty urls and all that)

Would you be interested in making these kinds of things configurable so that this can run in a "jekyll mode", or should I fork off?

[rolodato]

An option for specifying the output directory definitely makes sense. I'd like it to be explicit and not default to anything, that way users have to explicitly state that they want their certificate persisted to disk. If no directory is specified, it should keep the current behavior.

Oddly enough I've tested this with Jekyll and didn't need the layout: null option nor the trailing slash, but maybe my server is configured differently (I haven't dived deep into the different Jekyll options). I'm skeptical of adding specific modes for different applications, maybe there's a Jekyll setting we can change instead?

[JustinAiken]

An option for specifying the output directory definitely makes sense. I'd like it to be explicit and not default to anything, that way users have to explicitly state that they want their certificate persisted to disk. If no directory is specified, it should keep the current behavior.

👍

Oddly enough I've tested this with Jekyll and didn't need the layout: null option

• If you have anything like this in the _config.yml:

defaults:
    layout: post

You have to override the layout with layout: null
That can probably be worked around from the config instead of the challenge content though..

nor the trailing slash, but maybe my server is configured differently (I haven't dived deep into the different Jekyll options).

With gitlab pages and Jekyll, I seem to either have to have a trailing slash (making it actually a folder/index.html, or a .html on the end - I can't get a link to just a plain extensionless file work..

[rolodato]

I just realized you weren't mentioning anything about the local output directory, sorry about that. A filepath option for specifying the remote path for the challenge file sounds great.

put instead of post, since I already had an old challenge file existing - needed to update instead of create

In my tests this wasn't necessary - I could start a challenge, not complete it, then start a new one and it would work just fine, even if I didn't delete the old challenge file. Were you seeing different behavior?

About the Jekyll-specific behavior, I think it makes sense to add because of how common Jekyll is for GitLab Pages specifically. We can add a jekyll flag that outputs the challenge file to the correct directory and in the correct format. It should work on a freshly created site created on the latest Jekyll version with jekyll new, and hosted on GitLab pages with the default settings.

It will be a while before I can get to work on this (hopefully graduating next month!) so a PR would be much appreciated. Thanks!

[JustinAiken]

In my tests this wasn't necessary - I could start a challenge, not complete it, then start a new one and it would work just fine, even if I didn't delete the old challenge file. Were you seeing different behavior?

With the way my Jekyll blog is setup (I think this is The Jekyll Way, but I could be wrong), I'm using the same file in source control, which has the URL set through front-matter - so each request will be editing the same file in source control, even if it's a new challenge filename..

But I think you can also set Jekyll up to just dump files straight up, so it may be easier to just reconfigure Jekyll than to rewrite parts of this plugin...

It will be a while before I can get to work on this (hopefully graduating next month!) so a PR would be much appreciated. Thanks!

I'll investigate config options,and maybe at least do a documentation PR that helps setup Jekyll to work closer to the defaults of this plugin...

[JustinAiken]

... ended up making a Jekyll plugin in Ruby; figured it made the most sense for Jekyll integration:

• jekyll-gitlab-letsencrypt