controllers: move controllers base class from lib/base to controllers

TG quickstart put it in lib/base.py , but it fits better on the controllers
layer as a base there.

The contributing docs were a bit ahead of time ... but with a typo.

lib: consistently import helpers the same way

Make it easier to grep for any remaining potential layering-violating use of
helpers.

autocomplete: also match on email address

There are cases where the firstname/lastname known to Kallithea, is not
complete, perhaps only an initial. But users that try to add a reviewer, may
start typing a full name and expect autocompletion.

For example:

firstname: John
lastname: D
email: john.doe@example.com

When a review starts typing 'Doe' they will not get any matches if
autocompletion is purely based on names.

This situation sometimes arises with Indian developers, where the names
known to companies may be abbreviated as initials. For example "C K Deepak"
where Deepak is the first name and C K are the initials of the last name.

autocomplete: also query 'firstname lastname' and 'lastname firstname' combinations

The autocomplete functionality for user names, e.g. in pull request reviewer
lists, @mentions, etc. would match the input term only on firstname,
lastname or username, but not a combination of firstname lastname.

This is a problem when there are many matches on the same firstname or
lastname, in particular with Chinese names like 'Wang', 'Cheng', etc. If you
know the full name and type it, you would not get any matches.

Instead, adapt the queries to also match on 'firstname lastname' and
'lastname firstname'.

This means that simple matching on only username or only lastname, can be
removed.

home: don't send _changeset_cache in repo_switcher_data result

It is unused, and it is problematic to serialize bytes in json ... and it is
especially obvious in py3.

home: drop disabled caching of repo_switcher_data

The caching condition has been False since ffd45b185016 . That makes sense -
caching as implemented would leak the repo list of other users without
considering permissions. The repo list is however only loaded on demand, and
caching is not that important.

home: make sure users and group autocomplete is case insensitive

Both SQLite and MySQL have a case-insensitive LIKE operator by default, but
PostgreSQL does not. As a result, a query for 'john' does not match the user
'John Doe'.

As case-insensitivity is most user-friendly in the context of autocompletion
of users and groups, switch to the ilike() method of SQLAlchemy rather than
like().

auth: restore anonymous repository access

Dominik Ruf found that aa25ef34ebab introduced a regression in anonymous access
to repositories ... if that is enabled.

The refactoring was too strict when it missed that not all repo permission
checks require a logged in user. Read access can be granted to the default user
... but not write or admin.

Instead of the commands used in aa25ef34ebab, the following commands are used
to consistently also allow the default user in all decorators where we only need
repo read access:

# Introduce explicit allow_default_user=True - that was the default before aa25ef34ebab
sed -i 's/@LoginRequired()/@LoginRequired(allow_default_user=True)/g' `hg mani`
sed -i 's/@LoginRequired(\(..*\))/@LoginRequired(\1, allow_default_user=True)/g' `hg mani`
# The primary case: Replace @NotAnonymous with removal of allow_default_user=True
perl -0pi -e 's/\@LoginRequired\((?:(.*), )?allow_default_user=True\)\n\s*\@NotAnonymous\(\)/\@LoginRequired(\1)/g' `hg mani`
# If there is a global permission check, no anonymous is ever allowed
perl -0pi -e 's/\@LoginRequired\(allow_default_user=True\)(\n\s*\@HasPermission)/\@LoginRequired()\1/g' `hg mani`
# Repo access for write or admin also assume no default user
perl -0pi -e 's/\@LoginRequired\(allow_default_user=True\)(\n\s*\@HasRepoPermissionLevelDecorator\('"'(write|admin)'"'\))/\@LoginRequired()\1/g' `hg mani`

auth: refactor to introduce @LoginRequired(allow_default_user=True) and deprecate @NotAnonymous()

It was error prone that @LoginRequired defaulted to allow anonymous users (if
'default' user is enabled). See also 245b4e3abf39.

Refactor code to make it more explicit and safe by default: Deprecate
@NotAnonymous by making it the default of @LoginRequired. That will make it
safe by default.

To preserve same functionality, set allow_default_user=True in all the cases
where @LoginRequired was *not* followed by @NotAnonymous or other permission
checks - that was done with some script hacks:
sed -i 's/@LoginRequired(\(..*\))/@LoginRequired(\1, allow_default_user=True)/g' `hg mani`
sed -i 's/@LoginRequired()/@LoginRequired(allow_default_user=True)/g' `hg mani`
perl -0pi -e 's/\@LoginRequired\(allow_default_user=True\)\n\s*\@NotAnonymous\(\)/\@LoginRequired()/g' `hg mani`
perl -0pi -e 's/\@LoginRequired\(allow_default_user=True\)(\n\s*\@Has(Repo)?Permission)/\@LoginRequired()\1/g' `hg mani`

It has been reviewed that all uses of allow_default_user=True are in places
where the there indeed wasn't any checking for default user before. These may
or may not be correct, but now they are explicit and can be spotted and fixed.

The few remaining uses of @NotAnonymous should probably be removed somehow.

js: use ajax requests for select2 autocomplete

When you have a big user base, with thousends of users, always using the whole
dataset makes the UI slow.

This will replace kallithea/model/repo.py get_users_js and get_user_groups_js
which were used to inline the full list of users and groups in the document.
Instead, it will expose a json service for doing the completion.

When using the autocomplete, there might be multiple ajax requests, but tests
with a userbase > 9000 showed no problems.
And keep in mind, that although we now make multiple requests (one for every
character) that
- the autocomplete is not used that often
- the requests are quite cheap
- most importanly, we no longer need to calculate the user list/group list if
the user doesn't use the autocomplete

Users and groups are still passed as parameters to the javascript functions -
they will be removed later.

index: show repositories and repository groups in the same table

Having two different tables with their own paging and search gave a bad UI.
Instead, do like all other UIs that show directory content and show both
"folders" and "files" in the same list.

The rendering of repo groups is changed to use js data instead of a taking data
from an html table.

Repository groups are shoe-horned into the repository DataTable. The columns
are no perfect match - some of the existing columns are thus given an empty
default value.

codingstyle: trivial whitespace fixes

Reported by flake8.

controllers: remove empty __before__ methods

__before__ methods that only call the super __before__ method are redundant
and can be removed. The super's method will be called directly.

tg: minimize future diff by some mocking and replacing some pylons imports with tg

No actual tg dependency yet, just a temporary hack faking tg as an alias for
pylons.

Based on work by Alessandro Molina.

templates: properly escape inline JavaScript values

TLDR: Kallithea has issues with escaping values for use in inline JS.
Despite judicious poking of the code, no actual security vulnerabilities
have been found, just lots of corner-case bugs. This patch fixes those,
and hardens the code against actual security issues.

The long version:

To embed a Python value (typically a 'unicode' plain-text value) in a
larger file, it must be escaped in a context specific manner. Example:

>>> s = u'<script>alert("It\'s a trap!");</script>'

1) Escaped for insertion into HTML element context

>>> print cgi.escape(s)
&lt;script&gt;alert("It's a trap!");&lt;/script&gt;

2) Escaped for insertion into HTML element or attribute context

>>> print h.escape(s)
&lt;script&gt;alert(&#34;It&#39;s a trap!&#34;);&lt;/script&gt;

This is the default Mako escaping, as usually used by Kallithea.

3) Encoded as JSON

>>> print json.dumps(s)
"<script>alert(\"It's a trap!\");</script>"

4) Escaped for insertion into a JavaScript file

>>> print '(' + json.dumps(s) + ')'
("<script>alert(\"It's a trap!\");</script>")

The parentheses are not actually required for strings, but may be needed
to avoid syntax errors if the value is a number or dict (object).

5) Escaped for insertion into a HTML inline <script> element

>>> print h.js(s)
("\x3cscript\x3ealert(\"It's a trap!\");\x3c/script\x3e")

Here, we need to combine JS and HTML escaping, further complicated by
the fact that "<script>" tag contents can either be parsed in XHTML mode
(in which case '<', '>' and '&' must additionally be XML escaped) or
HTML mode (in which case '</script>' must be escaped, but not using HTML
escaping, which is not available in HTML "<script>" tags). Therefore,
the XML special characters (which can only occur in string literals) are
escaped using JavaScript string literal escape sequences.

(This, incidentally, is why modern web security best practices ban all
use of inline JavaScript...)

Unsurprisingly, Kallithea does not do (5) correctly. In most cases,
Kallithea might slap a pair of single quotes around the HTML escaped
Python value. A typical benign example:

$('#child_link').html('${_('No revisions')}');

This works in English, but if a localized version of the string contains
an apostrophe, the result will be broken JavaScript. In the more severe
cases, where the text is user controllable, it leaves the door open to
injections. In this example, the script inserts the string as HTML, so
Mako's implicit HTML escaping makes sense; but in many other cases, HTML
escaping is actually an error, because the value is not used by the
script in an HTML context.

The good news is that the HTML escaping thwarts attempts at XSS, since
it's impossible to inject syntactically valid JavaScript of any useful
complexity. It does allow JavaScript errors and gibberish to appear on
the page, though.

In these cases, the escaping has been fixed to use either the new 'h.js'
helper, which does JavaScript escaping (but not HTML escaping), OR the
new 'h.jshtml' helper (which does both), in those cases where it was
unclear if the value might be used (by the script) in an HTML context.
Some of these can probably be "relaxed" from h.jshtml to h.js later, but
for now, using h.jshtml fixes escaping and doesn't introduce new errors.

In a few places, Kallithea JSON encodes values in the controller, then
inserts the JSON (without any further escaping) into <script> tags. This
is also wrong, and carries actual risk of XSS vulnerabilities. However,
in all cases, security vulnerabilities were narrowly avoided due to other
filtering in Kallithea. (E.g. many special characters are banned from
appearing in usernames.) In these cases, the escaping has been fixed
and moved to the template, making it immediately visible that proper
escaping has been performed.

Mini-FAQ (frequently anticipated questions):

Q: Why do everything in one big, hard to review patch?
Q: Why add escaping in specific case FOO, it doesn't seem needed?

Because the goal here is to have "escape everywhere" as the default
policy, rather than identifying individual bugs and fixing them one
by one by adding escaping where needed. As such, this patch surely
introduces a lot of needless escaping. This is no different from
how Mako/Pylons HTML escape everything by default, even when not
needed: it's errs on the side of needless work, to prevent erring
on the side of skipping required (and security critical) work.

As for reviewability, the most important thing to notice is not where
escaping has been introduced, but any places where it might have been
missed (or where h.jshtml is needed, but h.js is used).

Q: The added escaping is kinda verbose/ugly.

That is not a question, but yes, I agree. Hopefully it'll encourage us
to move away from inline JavaScript altogether. That's a significantly
larger job, though; with luck this patch will keep us safe and secure
until such a time as we can implement the real fix.

Q: Why not use Mako filter syntax ("${val|h.js}")?

Because of long-standing Mako bug #140, preventing use of 'h' in
filters.

Q: Why not work around bug #140, or even use straight "${val|js}"?

Because Mako still applies the default h.escape filter before the
explicitly specified filters.

Q: Where do we go from here?

Longer term, we should stop doing variable expansions in script blocks,
and instead pass data to JS via e.g. data attributes, or asynchronously
using AJAX calls. Once we've done that, we can remove inline JavaScript
altogether in favor of separate script files, and set a strict Content
Security Policy explicitly blocking inline scripting, and thus also the
most common kind of cross-site scripting attack.

auth: simplify repository permission checks

In practice, Kallithea has the 'repository.admin' permission imply the
'repository.write' permission, which again implies 'repository.read'.

This codifies/enforces this practice by replacing HasRepoPermissionAny
"perm function" with the new HasRepositoryLevel function, reducing the
risk of errors and saving quite a lot of typing.

lib: move jsonify from utils to base

Suggested by Mads Kiilerich.

The jsonify method is the only thing in utils that directly uses pylons.
Move it to base where it fits better and we can use existing global imports.

db: do case-insensitive explicit sorting of RepoGroup names

This does not change the implicit sorting enabled via __mapper_args__,
which is a bad idea anyway (and now deprecated), and will have to be
dealt with in a later changeset.

The use of __mapper_args__ implicitly adds sorting to every query of
RepoGroup objects throughout the code (including implicit queries via
relationships). For the relationships, __mapper_args can be replaced
with "order_by" on each individual relationship, and it's reasonably
straight-forward to identify every RepoGroup query throughout the code,
and add explicit sorting. But we don't really need that sorting most
of the time, so a better way forward may be to identify all the places
that actually needs the sorting, make it explicit there, and then kill
the __mapper_args__. (Anyway, future work.)

db: always do case-insensitive sorting of repository names

We retain the implicit order_by on the follows_repository relationship.
This is probably a bad idea, since it causes sorting even when it's not
needed; but for now, at least, we consistently do case-insensitive sort.

cleanup: remove dead code and templates related to 'Switch To'

a33448d81f70 introduced a new 'Switch To' functionality and removed the last
reference to branch_tag_switcher and thus to switch_to_list.html and the tags,
bookmarks and branches pages.

We don't need these pages ... and if we do, we will implement them differently.
They are mostly YUI datatables with compare links that only can compare within
the same kind of revision names.

scm: simplify get_repos and get rid of RepoList overloads

The RepoList variants might have made sense before any repo info was stored in
the database. Now it has no value and doesn't help at all.

menu: Added select2 box for "Switch To", work towards having general revision context

Major changes by Takumi IINO <trot.thunder@gmail.com>.

Correct licensing information in individual files.

The top-level license file is now LICENSE.md.

Also, in various places where there should have been joint copyright holders
listed, a single copyright holder was listed. It does not appear easy to add
a link to a large list of copyright holders in these places, so it simply
refers to the fact that various authors hold copyright.

In future, if an easy method is discovered to link to a list from those
places, we should do so.

Finally, text is added to LICENSE.md to point to where the full list of
copyright holders is, and that Kallithea as a whole is GPLv3'd.

Second step in two-part process to rename directories.
This is the actual directory rename.