Warning: the current version of Jingo (1.x.x) is relatively new and it has gone through some major rewrites. If you find yourself having problems with this version, you can still use the previous stable version 0.6.1. If this is the case, please take a minute and fill out one issue. And don't forget to take a look at the list of changes!

JINGO

A git based wiki engine written for node.js, with a decent design, a search capability and a good typography.

Introduction
Features
Installation
Authentication and Authorization
Common problems
Known limitations
Customization
Editing
Configuration options reference

Introduction

The aim of this wiki engine is to provide an easy way to create a centralized documentation area for people used to work with git and markdown. It should fit well into a development team without the burden to have to learn a complex and usually overkill application.

Jingo is very much inspired by (and format-compatible with) the github own wiki system Gollum, but it tries to be more a stand-alone and complete system than Gollum is.

Think of jingo as "the github wiki, without github but with more features". "Jingo" means "Jingo is not Gollum" for more than one reason.

There is a demo server running at http://jingo.cica.li:6067/wiki/home

Features

No database: it uses a git repository as the document archive
No user management: authentication is provided via a 3rd party provider or a simple, one-user login
Markdown for everything, github flavored
Uses Codemirror or Markitup as the markup editor, with a nice (ajax) preview (see the features key in the config file)
Provides a "distraction free", almost full screen editing mode
Compatible with a wiki created with the Gollum wiki
Revision history for all the pages
Show differences between document revisions
Paginated list of all the pages, with a quick way to find changes between revisions
Search through the content and the page names
Layout accepts custom sidebar and footer
Gravatar support
Can include IFRAMEs in the document (es: embed a Google Drive document)
Can use custom CSS and JavaScript scripts
White list for authorization on page reading and writing
Detects unwritten pages (which will appear in red)
Automatically push to a remote
Mobile friendly (based on Bootstrap 3.x)
Quite configurable, but also works out of the box

For code syntax highlighting, Jingo uses the node-syntaxhighlighter module. For the list of supported languages, please refer to this page.

Installation

npm install jingo or download/clone the whole thing and run "npm install".

Jingo needs a config file and to create a sample config file, just run jingo -s, redirect the output on a file and then edit it (jingo -s > config.yaml). The config file contains all the available configuration options. Be sure to provide a valid server hostname (like wiki.mycompany.com) if you use a 3rd party provider for authentication (like Google or GitHub). It is needed for them to be able to get back to you.

This document contains also the reference for all the possible options.

If you define a remote to push to, then Jingo will automatically issue a push to that remote every pushInterval seconds. You can also specify a branch using the syntax "remotename branchname". If you don't specify a branch, Jingo will use master. Please note that before the push, a pull will also be issued (at the moment Jingo will not try to resolve conflicts, though).

The basic command to run the wiki will then be

jingo -c /path/to/config.yaml

Before running jingo you need to initialise its git repository somewhere (git init is enough). Additionally the user running the process needs to have git config --global user.name and git config --global user.email configured. Else your document's repo will get scrambled and you have to reinitialize it again (rm -rf .git && git init).

If you define a remote to push to, be sure that the user who'll push has the right to do so. This means you have to configure the remote via the git:// URI that uses ssh authentication to push and have created and published the process user's ssh public key to the remote.

If your documents reside in subdirectory of your repository, you need to specify its name using the docSubdir configuration option. The repository path must be an absolute path pointing to the root of the repository.

If you want your wiki server to only listen to your localhost, set the configuration key localOnly to true.

Authentication and Authorization

You can enable the following strategies: Google logins (OAuth2), GitHub logins (OAuth2) or a simple, locally verified username/password credentials match (called "alone"). If you use the alone method, you can have only one user accessing the wiki (thus the name).

The Google Login and the GitHub login uses OAuth 2 and that means that on a fresh installation you need to get a client id and a client secret from Google or GitHub and put those informations in the configuration file.

For Google, follow these instructions (you need to be logged in in Google):

Open the Google developer console
Create a new project (you can leave the Project id as it is). This will take a little while
Open the Consent screen page and fill in the details (particularly, the product name)
Now open APIs & auth => Credentials and click on Create new client id
Here you need to specify the base URL of your jingo installation. Google will fill in automatically the other field with a /oauth2callback URL, which is fine
Now you need to copy the Client ID and Client secret in your jingo config file in the proper places

For GitHub, follow these instructions (you need to be logged in in GitHub):

Register a new application here
Enter whatever Application name you want
Enter your installation URL (localhost is OK, for example "http://localhost:6767/")
Enter /auth/github/callback as the Authorization callback URL
Press the Register application button
In the following page, on the top right corner, take note of the values for Client ID and Client Secret
Now you need to copy the Client ID and Client secret in your jingo config file in the proper places

The alone method uses a username, a passwordHash and optionally an email. The password is hashed using a non salted SHA-1 algorithm, which makes this method not the safest in the world but at least you don't have a clear text password in the config file. To generate the hash, use the --hash-string program option: once you get the hash, copy it in the config file.

You can enable all the authentications options at the same time. The alone is disabled by default.

The authorization section of the config file has two keys: anonRead and validMatches. If the anonRead is true, then anyone who can access the wiki can read anything.

If anonRead is false you need to authenticate also for reading and then the email of the user must match at least one of the regular expressions provided via validMatches, which is a comma separated list. There is no "anonWrite", though. To edit a page the user must be authenticated.

The authentication is mandatory to edit pages from the web interface, but jingo works on a git repository; that means that you could skip the authentication altogether and edit pages with your editor and push to the remote that jingo is serving.

Common problems

Sometimes upgrading your version of node.js could break the iconv module. Try updating it with npm install iconv.

Known limitations

The authentication is mandatory (no anonymous writing allowed). See also issue #4
The repository is "flat" (no directories or namespaces)
Authorization is only based on a regexp'ed white list with matches on the user email address
There is one authorization level only (no "administrators" and "editors")
At the moment there is no "restore previous revision", just a revision browser
No scheduled pull or fetch from the remote is provided (because handling conflicts would be a bit too... interesting)

Please note that at the moment it is quite "risky" to have someone else, other than jingo itself, have write access to the remote / branch jingo is pushing to. The push operation is supposed to always be successfull and there is no pull or fetch. You can of course manage to handle pull requests yourself.

Customization

You can customize jingo in four different ways:

add a left sidebar to every page: just add a file named _sidebar.md containing the markdown you want to display to the repository. You can edit or create the sidebar from Jingo itself, visiting /wiki/_sidebar (note that the title of the page in this case is useless)
add a footer to every page: the page you need to create is _footer.md and the same rules for the sidebar apply
add a custom CSS file, included in every page as the last file. The default name of the file is _style.css and it must reside in the document directory (but can stay out of the repo). It is not possible to edit the file from jingo itself
add a custom JavaScript file, included in every page as the last JavaScript file. The default name of the file is _script.js and it must reside in the document directory (but can stay out of the repo). It is not possible to edit the file from jingo itself

All these names are customizable via the customizations option in the config file (see the reference).

Once read, all those files are cached (thus, not re-read for every page load, but kept in memory). This means that for every modification in _style.css and _script.js you need to restart the server (sorry, working on that).

This is not true for the footer and the sidebar but ONLY IF you edit those pages from jingo (which in that case will clear the cache by itself).

Editing

To link to another Jingo wiki page, use the Jingo Page Link Tag.

[[Jingo Works]]

The above tag will create a link to the corresponding page file named jingo-works.md. The conversion is as follows:

Replace any spaces (U+0020) with dashes (U+002D)
Replace any slashes (U+002F) with dashes (U+002D)

If you'd like the link text to be something that doesn't map directly to the page name, you can specify the actual page name after a pipe:

[[How Jingo works|Jingo Works]]

The above tag will link to Jingo-Works.md using "How Jingo Works" as the link text.

Images

If you put images into the repository, Jingo will be able to serve them. You can enable Jingo to serve even other file types from the document directory: you need to change the staticWhitelist configuration option.

Configuration options reference

####application.title

This will be showed on the upper left corner of all the pages, in the main toolbar

####application.repository

Absolute path for your documents repository (mandatory).

####application.docSubdir

If your documents reside inside a directory of the repository, specify its name here.

####application.remote

This is the name of the remote you want to push/pull to/from (optional). You can also specify a specific branch using the syntax “remotename branchname”. If you don’t specify a branch, Jingo will use master.

####application.pushInterval

Jingo will try to push to the remote (if present) every XX seconds (defaults to 30)

####application.secret

Just provide a string to be used to crypt the session cookie

####application.git

You can specify a different git binary, if you use more than one in your system

####application.skipGitCheck

Jingo will refuse to start if it founds a version of git which is known to be problematic. You can still force it to start anyway, providing true as the value for this option

####application.loggingMode

Specifies how verbose the http logging should be. Accepts numeric values: 0 for no logging at all, 1 for the a combined log and 2 for a coincise, coloured log (good for development). Default is 1.

####application.pedanticMarkdown

Boolean, defaults to true (was false in jingo < 1.1.0)

The markdown module we use (Marked) tries to overcome some "obscure" problems with the original Perl markdown parser by default. These produces some problems when rendering HTML embedded in a markdown document (see also issue claudioc#48. By default we now want to use the original parser and not the modified one (pedantic: true).

With this option you can revert this decision if for some reason your documents are not rendered how you like.

####authentication.staticWhitelist

This is to enable jingo to serve any kind of static file (like images) from the repository. By default, Jingo will serve *.md files and *.jpg, *.png, *.gif. Provide the values as a comma separated list of regular expressions.

####authentication.google.enabled

Boolean, defaults to true

####authentication.google.clientId ####authentication.google.clientSecret

Values required for Google OAuth2 authentication. Refer to a previous section of this document on how to set them up.

####authentication.github.enabled

Boolean, defaults to false

####authentication.github.clientId ####authentication.github.clientSecret

Values required for GitHub OAuth2 authentication. Refer to a previous section of this document on how to set them up.

####authentication.alone.enabled

Boolean, defaults to false

####authentication.alone.username

Provide any username you like, as a string

####authentication.alone.passwordHash

Use an hash of your password. Create the hash with jingo -# yourpassword

####authentication.alone.email

If you want to use Gravatar, provide your gravatar email here.

####features.markitup

Boolean, whether to enable Markitup or not (default false)

####features.codemirror

Boolean, whether to enable Codemirror or not (default true)

Please note that you cannot enable both editors at the same time.

####server.hostname

This is the hostname used to build the URL for your wiki pages. The reason for these options to exist is due to the need for the OAuth2 authentication to work (it needs an endpoint to get back to)

####server.port

Jingo will listen on this port

####server.localOnly

Set this to true if you want to accept connection only from localhost (default false)

####server.baseUrl

Not used anymore (built with "//" + hostname + ":" + port)

####authorization.anonRead

Boolean to enable/disable the anonymous access to the wiki content (default true)

####authorization.validMatches

This is a regular expression which will be used against the user email account to be able to access the wiki. By default all google powered emails are OK, but you can for example set a filter so that only the hostname from your company will be allowed access.

####pages.index

Defines the page name for the index of the wiki (default is "Home")

####pages.title.fromFilename

If this is true, the title of each page will be derived from the document's filename. This is how Gollum works and from Jingo 1.0 this is now the default (default true). An important consequence of this behavior is that now Jingo is able to rename documents (according to the new name it will be eventually given to), while previously it was impossible.

####pages.title.fromContent

If this is true, the title of the document will be part of the document itself (the very first line). This is the default behavior of Jingo < 1.0 and the default is now false. If you have an old installation of Jingo, please set this value to true and fromFilename to false.

####pages.title.asciiOnly

If this is set to true, Jingo will convert any non-Ascii character present in the title of the document to an ASCII equivalent (using iconv), when creating the filename of the document. Default was true for Jingo < 1.0 while for Jingo >= 1.0 the default is false

####pages.title.lowercase

If this is set to true, Jingo will lowercase any character of the title when creating the filename. Default was true for Jingo < 1.0 while for Jingo >= 1.0 the default is false

####pages.title.itemsPerPage

This defines how many page item to show in the "list all page" page. Keep this value as low as possible (default to 10) for performance reasons.

####customizations.sidebar

Defines the name for the sidebar component. Defaults to _sidebar.md. Please note that if you need to use a wiki coming from Github, this name should be set to _Sidebar

####customizations.footer

Defines the name for the footer component. Defaults to _footer.md. Please note that if you need to use a wiki coming from Github, this name should be set to '_Footer'

####customizations.style

Defines the name for the customized style CSS component. Defaults to _style.css.

####customizations.script

Defines the name for the customized script JavaScript component. Defaults to _script.js.

bqba / jingo