Online editing

[qaisjp]

A long term plan is to get editing right within the website, rather than just on GitHub.

gollum / gollum-lib seems like a really good base, but this will not be an easy feat.

[qaisjp]

So on July 28 I contacted Informatics Computing Services about getting authentication behind Informatics' Cosign service.

Today we've gotten the OK at first sight, and they are going to discuss this next week (person managing the Cosign service is off work this week). This is looking positive!

[qaisjp]

We have the Cosign service working in a quick telnet-esque test. Here's the game plan:

• move content to a simple folder structure not running on jekyll (this would be the "content" repo)

then, one of the following:

A) write a new website in Ruby (with the use of gollum) to edit the content repo
B) Keep with jekyll, but add client side authentication (+ write an API) with client side editing, and so on

[qaisjp]

This is going pretty well!

I've written a library to interact with the CoSign daemon. Anything living on Tardis can interact with cosign-webapi instead.

Proof of concept of CoSign working can be found here, on the map! (Log in on the map before visiting the next link..)

A Better Informatics "API", of sorts, can be found at provider.betterinformatics.com (https only). The code for bi-provider is open-source, of course!

[rphi]

That Cosign thing is very neat indeed....

I started typing things and realised I have no idea what I'm talking about RE editing, but I'd probably vote for having the site remain on Jekyll. Alternatively and an idea that you haven't already mentioned, is maybe even serve the site content as Markdown files direct from the repository and then use a client side library to parse the MD on the fly. Then for editing, just click to swap to the raw MD. How you'd get the changes back to Github is another question entirely and would probably need something awful.

[Visgean]

I think the way to go here is simply use commits signed by the cosign user.

[rphi]

Oh of course, because in Git there is no authentication on who you say you are in the commits is there? So we could give the back-end an API key which it could use for all users' edits?

Also just come across this that might come in handy: Github Contents API

[Visgean]

You dont need that, you can simply commit the changes and sign it with the cosign email.

…

On Tue, 7 Nov 2017, 20:30 Robert Phipps, ***@***.***> wrote: Oh of course, because in Git there is no authentication on who you say you are in the commits is there? So we could give the back-end an API key which it could use for all users' edits? Also just come across this that might come in handy: Github Contents API <https://developer.github.com/v3/repos/contents/> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#23 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAL1KIwQv9XA2XYu10X0LFXMmPJJFI09ks5s0L31gaJpZM4OSMTx> .

[rphi]

But to push to the repository you need to authenticate?

[rphi]

(assuming this still needs you to be on the CompSoc Github team to push)

[qaisjp]

I'm hoping for us to integrate editing within the Better Informatics website.

It shouldn't be just 3-5 people contributing content, and people are much more likely to contribute if they can click a big edit button and make a change immediately, rather than having to create a GitHub accounts. Unfortunately a lot of students don't know how to use Git.

Right now my plan is:

• First write a small form that will link your DICE account to GitHub, automating the GitHub team process.
• Do the same thing for Google Drive, as the Team Drive is private unless you request access. (We have been receiving requests.) done!
• Do a /my page, showing your courses, as it should be fairly simple. (bi-provider is one half of that) Update: this has been done but we have a problem with LDAP access
• Then write an interface of edit file + commit, where editing in the browser will send the change to the server, and create a commit for you. (Which is sent back to GitHub.)
• Then move away from Jekyll, but keep the edit file + commit system with GitHub, as I'm fairly keen on leveraging Git for version control.

Moving away from Jekyll would be ideal as we don't have that many pages, and we have a lot of metadata (about courses) that could be pulled externally (such as what semester courses are in, what courses are available, course names, etc).

But even when moving away from Jekyll, all the real content would still be stored in markdown files, visible on GitHub.