Wicket 7 #1231
Open
Wicket 7 #1231
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…s to generate user cookies
The canAdmin permission is set on a LDAP user, when the user is listed in `realm.ldap.admins` or is a member of a team listed in `realm.ldap.admins`. This leads to inconsistent and surprising behaviour on the EditUser page when clicking the "can admin" checkbox. Also, the "can admin" checkbox is disabled, but not checked, for teams that are listed as admin teams. The new behaviour implemented in this patch makes users and teams from LDAP match local ones. That means: * LDAP teams that are listed in `realm.ldap.admins` get the canAdmin property set if teams are maintained in LDAP. * LDAP users that are listed in `realm.ldap.admins` get the canAdmin property set if teams are maintained in LDAP. * LDAP users do not get the canAdmin property set, if they are only a member of a team listed in `realm.ldap.admins`. * The `supportsRoleChanges` method for users and teams of the `LdapAuthProvider` unconditially returns false if teams are maintained in LDAP, not only for users and teams listed in `realm.ldap.admins`. * Therefore, for all LDAP users and teams the "can admin" checkbox is always disabled if teams are maintained in LDAP.
Set "can admin" permission on LDAP users and teams correctly
Extract the creation of the in-memory servers and the interceptor code to a base class that LDAP related unit tests can extend to have the servers available.
Extract the inner class `LdapConnection` from the `LdapAuthProvider` into a separate class, so that it can be used from multiple classes that have to connect to an LDAP directory. The new class is placed into the new package `com.gitblit.ldap`, since it isn't specific to authentication.
Add new class `LdapPublicKeyManager` which retrieves public SSH keys from LDAP. The attribute can be configured with the new configuration option `realm.ldap.sshPublicKey`. The setting can be a simple attribute name, like `sshPublicKey`, or an attribute name and a prefix for the value, like `altSecurityIdentities:SshKey`, in which case attributes are selected that have the name `altSecurityIdentities` and whose values start with `SshKey:`.
Make the SSH authentication methods used by the server configurable, so that for example password authentication can be turned off. For this, a `git.sshAuthenticationMethods` setting is added which is a space separated list of authentication method names. Only the methods listed will be enabled in the server. This is modeled after the option of the same name from sshd_config, but it does not offer listing multiple required methods. It leaves the door open, though, for a later extension to support such a multi-factor authentication. Since this also includes Kerberos authentication with GSS API, this obsoletes the `git.sshWithKrb5` property. The latter is removed. Instead, to enable Kerberos5 authentication, add the method name `gssapi-with-mic` to the authentication methods list.
Instead of using fixed ports for the listeners of the in-memory LDAP server, let the listeners select ports and then save them in the authentication mode instance. This way we prevent port collisions, which especially showed up under Windows.
The `SshKeysDispatcher` tests that use the keys list command are failing on Windows because they assume a Unix line ending after each key. But the command will use a system line ending. So this fix uses system line endings in the reference string for the assert, too. In addition, two `assertTrue(false)´ are replaced with a proper `fail`.
Some public key mangers may be read-only, i.e. not allow to add or delete keys, or to change the key comment or assigned permissions. In such a case the respective commands should not be available on the SSH shell and the SSH Keys panel should also not offer the possibility. The `IPublicKeyManager` gets three new methods, modelled after the `AuthenticationManager`: `supportsWritingKeys`, `supportsCommentChanges` and `supportsPermissionChanges`. They return true if a key manager allows for keys to be written or updated. For example the existing `FileKeyManager` will return true for all three since it allows to store and update keys in a file. The new `LdapKeyManager` returns false since it only accesses LDAP and can not add or update any keys in the directory. A future key manager might get keys from an LDAP directory but still keep comments and permissions for it in a local copy. If writing of keys is not supported: * the welcome shell does not suggest adding a key, * the `SshKeysDispatcher` does not offer the "add", "remove", "comment" and "permission" commands, and * the SSH keys panel hides the "delete" button in the key list, and the "Add Key" form. The hiding of the "Add key" form is not perfect since the surrounding div is still shown, but I don't know how to hide it and it didn't look too bad, either.
Mark the user authentication cookie to be only used for HTTP, making it inaccessible for JavaScript engines. If only HTTPS is used and no HTTP (i.e. also if HTTP is redirected to HTTPS) then mark the user cookie to be sent only over secure connections.
So far for session cookies the secure property was only set when no HTTP port was opened. This changes to also set it when HTTP is redirected to the HTTPS port.
The regular expression used for user mentions used to work only inside sentences. Also, since it tested for whitespace, the whitespace would get replaced, too, which would join lines together. Instead the new regex uses boundary matchers to match against word boundaires. As these are not capturing only the actual user mention can be captured and is then replaced. Also, this way the regex can ignore punctuation like in "@jim, look at this." Since Gibtlit now requires Java 7 we can use named capture groups. This makes the use of a centrally defined regular expression much safer. The (admittedly only) group to capture the user name is named "user" and can be referenced by this name. By using the name instead of a group number, the regex could be changed without the code using it breaking because the group number changed. A simple test is added for user mentions, which unfortunately has to deal with the full markdown replacement, too. Fixes #985
Introduce our own wrapper `SecureRandom` around `java.security.SecureRandom`. This a) makes sure that the PRNG is seeded on creation and not when random bytes are retrieved, and b) uses a static instance in the `UserModel` so that lags do not occur during operation due to potentially seeding getting blocked on Unix when reading from the system's entropy pool. To keep the random data still secure, the static instance will reseed all 24 hours, also a functionality of the wrapper class. This fixes #1063 and extends and closes PR #1116
Secure cookies
Fixes the build that was broken by cherry-picking commit 2be2c2, which resulted in an import collision on the `SecureRandom` class.
LDAP SSH key manager
Use explicit coordinates, and therefor version numbers fro JUnit in the build.moxie file. It should not be some version that just happens to be used. Update JUnit to latest 4.12. Update JaCoCo to lates 0.7.8, which makes it work under Java 8. The last used version would fail when tests are run under Java 8.
…ntimeManager as a parameter
Better Czech localization
Exclude Lucene dependencies `lucene-spatial` and `lucene-join`. They were added during the update but are not needed. This patch excludes them explicitly so that they do not show up in the generated IDE files and `ext` directory.
To be able to read and migrate Lucene indices from old (4.x) formats to new (5.x) ones, add the `lucene-backward-codecs` library to the project. It is added to the `ext` directory and therefore to the classpath. According to the Lucene documentation, having it in the classpath can affect performance. But right now the `ext` directory is the only one available and even for a separate tool for offline migration the library would be needed.
… page.
Update the link target to the query parser syntax page of the 5.5 version.
Refactor the `LuceneSearchPage` to use an `ExternalLink` for the link
to the lucene page, so that the link target is kept and updated in the
Java code. Move the link out of the language files. This was way too
cumbersome to update the link target (which is probably why no one ever
did).
The query help text is changed to contain a variable:
`gb.queryHelp = here be some ${querySyntax} help`, which is replaced by
Wicket with a link.
The link text is a new lange file property: `gb.querySyntax`.
Also replace deprecated `search` method with the one without a filter argument, since the filter isn't used anyhow.
In order to support sorting, Lucene 5 needs DocValue fields in an index. So in order to make the ticket index work, i.e. show any tickets on the tickets page, the ticket index needs to be changed, adding a DocValues field. The DocValuesFields are implemented for the current index, which does not use multiple values for a field. Should at any time in the future an existing numeric field get multiple values stored in a document, then the index needs to know that and use SortedNumeric DocValues and SortFields instead.
In order to be able to update the index definition, the ticket index is assigned a version number, 2. This way the definiton can be updated and compatability with existing index files can be checked. The actual index is stored in a directory of name `indexVersion_codecVersion`. This wayit is veriy easy to check if an index of a certain version exists on the filesystem. It allows to have multiple indexes of different versions present, so that a downgrade of the software is possible without having to reindex again. Of coure, this is only possible if no new tickets were created since these would be missing in the old index. A new class `LuceneIndexStore` is introduced, which abstracts away the versioned index directory. The idea is, that this provides one place to keep the Lucene codec version and to allow to code compatibility rules into this class, so that older indices can still be used if they are compatible.
Change from the index version of a repository index being stored in a config file to also using index directories with the version in the name. For that, `LuceneRepoIndexStore` is added, which adds the fixed `lucene` part to the path. It also gives out the location of the `lucene.conf` file, which is now stored in the index directory. This way it is automatically deleted when the directory is deleted. I believe that it should also provide means to store branch aliases and tips, i.e. hide the config file completely. But this isn't implemented with this commit, the `LuceneService` is still aware that a config file is used.
This reverts commit 662fb90.
Check if tickets need to be reindexed when the server starts. This is the case if no ticket index exists. In that case the ticket index is built. This is done during the start of the `ITicketService`. For this the interface of `ITicketService` needed to change. The `start` method was defined abstract and the specific ticket services had to implement it. None does any real starting stuff in it. The `start` method is now final. It calls a new abstract method `onStart` which the specific ticket services need to implement. In the existing implementations I just changed `start` to `onStart`.
Bump to Lucene 5.5.2 The new code will create Lucene indices in a new directory named after codec and index version. This provides for easy and safe up- and downgrades. But it also means that the old indices will stick around on disk. What this version is missing is a kind of "garbage collection" deleting old, unused indices when they are no longer needed. That task needs to be done manually currently. We should at leas at some point provide a script for it.
merge upstream master
if key is empty of can not be parsed, form did provide any feedback to user before
This reverts commit c3e317a. Was added by mistake here. Should go into own branch to be able to merge with upstream using separate PR
Replace by native wicket functionality
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
merge latest developments from master into wicket-7 to keep branches in sync