auth: Fix bug where usernames are not consistently capitalized when using crowd login
If you try to log in to Kallithea via the Crowd auth module then the capitalization of your username in Kallithea changes on every login based on how you capitalized it in the login form.
E.g. Log in with "TestDude", username is entered as "TestDude" then log in again, but this time as "tesTduDe", and your username gets changed to "tesTduDe". etc.
Fix for this is to use the 'name' field returned from Crowd when saving the username. This way the username is always capitalized identically to the record in Crowd.
auth: Fix tomcat throwing '505 HTTP Version Not Supported' when trying to log in to Atlassian Crowd with usernames that contain spaces
If you try to log in to Kallithea via the Crowd auth module, and the username contains a space, it fails. Tomcat on the Crowd server gives error '505 HTTP Version Not Supported'.
Further investigation showed that the username was not being quoted. E.g. for the user 'test account', the REST URL should contain 'test%20account' but actually was containing 'test account'. When Tomcat received this HTTP request it interprets the word 'account' as the HTTP version because of the space. This obviously isn't a valid HTTP version.
This bug is fixed by using urllib2.quote on the username to ensure that special characters are correctly quoted. After making that change on my local install, the user 'test account' was able to log in successfully.
middleware: decode the repo_name received from http header to unicode
The middlewares seemed to make the incorrect assumption that the headers contained unicode. Or to put it differently: They relied on the Python default encoding to be able to convert to unicode instead of using safe_unicode. It would thus fail if running with LANG=C.
Instead, utilize that the header actually contains str_repo_name and explicitly decode that to unicode.
db: fix unknown exception type in commit error handling
efce61aac33d was a blind fix. It failed because `from sqlalchemy import *` doesn't import exc and the new except clause would thus fail. It also failed because the session has to be rolled back after a commit failure.
Now, rework it to fix these issues.
Note that we are able to detect whether the commit failed for valid reasons ... but we can't use that information to much ...
auth: fail pam and internal authentication attempts if no username is provided (Issue #180)
When the Mercurial client communicates with a server over HTTP, it will always first try to perform operations unauthenticated before providing credentials. Authentication attempts without credentials is usually pointless and will just slow operations down.
Some authentication plugins (such as LDAP) already skipped these unauthenticated requests. Now, do the same for other authentication plugions.
Other authentication plugins also skip if no password is provided ... but that doesn't seem necessary.
diff: get collapse target via .attr instead of .prop
Commit 3f017db297c4 was not fully tested and broke collapse/expand of diffs on changesets. $button is not a link with a target and the target can thus not be retrieved with .prop('target'); $button is just a span that happens to have a custom attribute with the name 'target'.
We thus revert back to the old way of retrieving it with .attr('target'). (It would perhaps be even better to use data attributes and name it data-target and use .data('target') ...)
files: fix Selection Link for multi-line selections
It broke in dacdea9fda2a when wrong casing in the translation lookup caused an undefined value which didn't show up in the UI and thus made the link unusable.
Commit b0774d79c7c95ec14ec6d23389d85ed544dd4b50 broke the 'Compare branches' button on the repository branches page, when attempting to replace a Yahoo UI click handler with jQuery.
Commit b0774d79c7c95ec14ec6d23389d85ed544dd4b50 broke the 'Compare bookmarks' button on the repository bookmarks page, when attempting to replace a Yahoo UI click handler with jQuery.
forms: don't use secure forms with authentication token for GET requests
The token is secret and should never be used in forms posted with GET which are URL encoded. aef21d16a262 was too aggresive in using secure forms everywhere and did thus also incorrectly use them for forms posted with GET.
Some token leakage was reported by Gjoko Krstic <gjoko@zeroscience.mk> of Zero Science Lab.
login: use server-relative URLs in came_from correctly
Using h.url to combine came_from with query parameters caused the SCRIPT_NAME to incorrectly be prepended to came_from, even though it was already present. This was not a problem if the Kallithea instance was served directly from the server root ('/') as is common, but broke setups where Kallithea was served from a prefix.
The login controller uses the came_from query argument to determine the page to continue to after login.
Previously, came_from specified only the URL path (obtained using h.url.current), and any URL query parameters were passed along as separate (additional) URL query parameters; to obtain the final redirect target, h.url was used to combine came_from with the request.GET.
As of this changeset, came_from specifies both the URL path and query string (obtained using request.path_qs), which means that came_from can be used directly as the redirect target (as always, WebOb handles the task of expanding the server relative path to a fully qualified URL). The mangling of request.GET can also be removed.
The login code appended arbitrary, user-supplied query parameters to URLs by calling the Routes URLGenerator (h.url) with user-supplied keyword arguments. This construct is unfortunate, since url only appends _unknown_ keyword arguments as query parameters, and the parameter names could overlap with known keyword arguments, possibly affecting the generated URL in various ways. This changeset removes this usage from the login code, but other instances remain.
(In practice, the damage is apparently limited to causing an Internal Server Error when going to e.g. "/_admin/login?host=foo", since WebOb returns Unicode strings and URLGenerator only allows byte strings for these keyword arguments.)
Even though only server-relative came_from URLs were ever generated, the login controller allowed fully qualified URLs (URLs including scheme and server). To avoid an open HTTP redirect (CWE-601), the code included logic to prevent redirects to other servers. By requiring server-relative URLs, this logic can simply be removed.
Note: SCRIPT_NAME is still not validated and it is thus possible to redirect from one app to another on the same netloc.
example.com is explicitly reserved for this purpose. Using that means we won't accidentally hammer a real server or real email address if an example value escapes into the wild, e.g. in an automated test.
The domain "kallithea.example.com" has been used throughout to refer to the example Kallithea server.
i18n: synchronised translations from the development branch
* updated the translation template * updated translation for Hungarian * updated translation for Russian * updated translation for French * added translation for Belarusian * updated translation for German * updated translation for Dutch (Belgium)
tooltips: fix unsafe insertion of userdata into the DOM as html
This fixes js injection in the admin journal ... and probably also in other places.
Tooltips are used both with hardcoded strings (which is safe and simple) and with user provided strings wrapped in html formatting (which requires careful escaping before being put into the DOM as html). The templating will automatically take care of one level of escaping, but here it requires two levels to do it correctly ... and that was not always done correctly.
Instead, by default, just insert it into the DOM as text, not as html.
The few places where we know the tooltip contains safe html are handled specially - the element is given the safe-html-title class. That is the case in file annotation and in display of tip revision in repo lists.
The API key generator abused temporary filenames in what seems to be an attempt of creating keys that unambiguously specified the user and thus were unique across users. A final hashing did however remove that property.
More importantly, tempfile is not documented to use secure random numbers ... and it only uses 6 characters, giving approximately 36 bits of entropy.
Instead, use the cryptographically secure os.urandom directly to generate keys with the same length but with the full 160 bits of entropy.
privacy: on password reset, don't tell strangers if email is valid or not
Password reset form might be used to check if users with specific email addresses have accounts in the system by requesting their password to be reset. It's probably not a good idea to give this sort of information to complete strangers.
issue: when deleting comments in a list of comments on the same line, sometimes the add new comment button stops working
root cause: when deleting a comment in a list of comments that are all on the same line, the wrong previous tr is chosen, the chosen tr could be an inline comments instead of a line tr, resulting in the fact that injectinlineform function will return immediatly
solution: loop over the found tr until its no longer an inline comment
remark: could probably be optimised futher to immediatly search for the line tr object
The Last Revision column of the file browser linked to URLs with the changeset as: r14:abcdef0123 which is not a valid changeset id. Instead, use .raw_id.
middleware: apply HttpsFixup to Hg/Git operations too (Issue #132)
Fix regression from 6a0964373a30. 'Require SSL for vcs operations' might make the protocol operations depend on the protocol type reported by a proxy even though they don't generate URLs.