Email verification and reCAPTCHA signup protection

Added this basic but fundamental protection layer to the website.

The email setup will of course be reused when notifications are eventually implemented.

Currently using SendGrid as the email provider. Very easy to setup, and has a free plan.

Adding reCAPTCHA immediately after email is a must otherwise an attacker could send infinitely many emails to random addresses, which would lead to the domain being marked as spam. I was pleasantly surprised about how easy the integration ended up being.

Issue tracker

 0  0 

Advances

Every article now has a (very basic) GitHub-like issue tracker. Comments now go under issues, and issues go under articles. Issues themselves are very similar to articles, with a title and a body.

This was part of 1.0, but not the first priority, but I did it now anyways because I'm trying to do all the database changes ASAP as I'm not in the mood to write database migrations.

Here's an example:

ourbigbook.com/go/issue/2/donald-trump/atomic-orbital a specific issue about the article "Atomic Orbital" by Donald Trump. Note the comments possibly by other users at the bottom.
ourbigbook.com/go/issues/1/donald-trump/atomic-orbital list of issues about the article "Atomic Orbital" by Donald Trump

https://raw.githubusercontent.com/cirosantilli/media/master/OurBigBook_issue_list_on_article_page.png

Insane links and parents

 0  0 

Advances

You can now write:

<Blue cats> are nice.

= Blue cat

= Big blue cat
{parent=Blue cat}

in lieu of the old:

\x[blue-cat]{c}{p} are nice.

= Blue cat

= Big blue cat
{parent=blue-cat}

`--format-source`

 0  0 

Advances

Added ourbigbook --format-source automatic code formatting. I implemented it for the following reasons:

I want to do certain automatic modifications to source code on web, e.g.:
- allow users to select the parent article of a new article on the web UI, but that is currently doable only with \Include macros
- allow users to edit the source only for a specific header
later on, much later, this will allow WYSIWYG export to plaintext

This also ended up having one unexpected benefit: whenever a new feature is added that deprecates an old feature, by converting the large corpus from github.com/cirosantilli/cirosantilli.github.io to the new feature I can test the new preferred feature very well.

For example, converting \x[blue cat] en masse to the new insane syntax <blue cat> found several bugs with the new insane syntax.

This seemed somewhat easy at first, so I started it as a way of procrastinating more urgent Web features (web scares me, you know), but it ended being insanely hard to implement, because there are many edge cases. Also, most bugs are not acceptable, as they would corrupt your precious source code and potentially output.

But well, it is done!