New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature 12866 #1255
Feature 12866 #1255
Conversation
c8398d0
to
0337210
Compare
Kudos, SonarCloud Quality Gate passed! |
95a0aab
to
e6c4e33
Compare
eaaf71b
to
a8291d5
Compare
You have successfully added a new SonarCloud configuration ``. As part of the setup process, we have scanned this repository and found no existing alerts. In the future, you will see all code scanning alerts on the repository Security tab. |
6bd36b4
to
e43ffed
Compare
e768b45
to
4c70ab3
Compare
acee9ed
to
1dd0afa
Compare
ac4b12b
to
d4ba0df
Compare
d4ba0df
to
8a082b2
Compare
Refactor the object model about the user authentication in order to define an API in core-api to authenticate a user for Silverpeas projects. For instance, this is required by the JCR implementation wrapper for Silverpeas. Rename some methods of JdbcSQlQuery to be more SQL-reading friendly.
Update version to 6.3-feature-12866 to avoid conflict with others developments.
In order to allow an access checking by the API token in other projects, add getToken() method to User and move some classes to the core-api module. Replace the use of UserDetail by User in some classes.
- SystemProperty to declare a property to set among the system properties through the SystemWrapper, - SystemProperties that is an array of one or more SystemProperty annotations. The goal of this annotation is to allow for tests extended with EnableSilverTestEnv JUnit 5 extension to set some system properties for the test managed beans and mocks before their initialization.
To allow Silverpeas projects to depend on core-api without having also to depend on its implementation (core-lib), some features in core-lib are copied into core-api. For instance, the functions to get a User by his login and domain, or by his API token are now declared in UserProvider. Some codes in core-lib and in core-rs using Administration to find a User by some of his data (login/domain, API token) are replaced by the use of UserProvider. Update consequently the integration tests.
After writing a Silverpeas project dedicated to provide a JCR implementation (wrapped by a small Silverpeas API), the code using previously and explicitly the JCR is now cleaned up in order to use this new project (Silverpeas-Archetype)
Take into account the JCR is now provided by the Silverpeas JCR lib. Update in consequence the integration tests based upon the JCR.
Take into account updates of some dependencies In H2, quote the reserved words used as fields in tables (in order to avoid SQL error with the latest version of the H2 driver).
Fix the way the versions are handled in Oak. Previously, with Jackrabbit 2, versioned nodes were simply simple versioned. In Jackrabbit Oak, the versioned nodes should be full versioned ones (simple versioning isn't taken into account in the versioning mechansim of Oak). Remove unused old JCR code. Fix some mispelled code and classe names. Take into account some feedbacks of Sonar.
The previous project Silverpeas JCR is now a subproject of Silverpeas Core. The package org.silverpeas.jcr from Silverpeas JCR is renamed to org.silverpeas.core.jcr. Below a synthesis of the work done on Silverpeas Core JCR. - Add code to abstract the implementation of the JCR under the hoods. In order to avoid to load any RepositoryFactory other than the ones provided by the Silverpeas backend of the JCR, the interface SilverpeasRepositoryFactory is defined. Any JCR implementation wrapper has to implement it. For instance, Apache Jackrabbit Oak is used as the default implementation of the JCR. - Add code to enable the configuration of the Oak repository from a properties file. This is an alternative to the OSGi configuration in Oak that has the drawback to depend on a lot of dependencies on both OSGi and Felix (an implementation of OSGi). The creation of the Oak repository is based upon the RepositoryFactory that is loaded from the Java Service Provider as expected in the JCR specifications. Silverpeas provides an implementation of this RepositoryFactory interface. The creation of the Oak repository is driven by the configuration loaded from a properties file whose the path has to be provided by the system property jcr.conf. It is the goal of the RepositoryFactory to create and configure the Oak repository from the loaded configuration properties whereas it is the goal of the RepositoryProvider to look for an available RepositoryFactory that knows how to treat the peculiar Silverpeas parameters for the JCR. Any use of the repository should ask for it to the RepositoryProvider which is a singleton. - The NodeStore in Oak requires to be closed/disposed at the ends of the application using the JCR in order to free some allocated resources (for example, the lock on the storage with the SegmentNodeStore. For doing, introduce the OakRepository and OakRepositoryConnection classes dedicated to wrap the Oak's repository implementation and to handle both the creation and the close of the repository (and hence of the NodeStore used behind). A new method is added to the interface SilverpeasRepositoryFactory: closeRepository; it is the symmetric operation of getting a repository in the RepositoryFactory interface. OakRepository extends SilverpeasRepository. - Add a LoginModule to authenticate a Silverpeas user by login/password and another one by token. - Add an initialization service to register a JCR schema for Silverpeas use. Add unit tests on the JCR schema registering. - Add a reentrant session mechanism: For instance, a session can be opened within a single thread by only one user, otherwise an exception is thrown. A session is distinguished by the userID with which it is mapped. The reentrant mechanism is based upon this distinction. For doing, based upon how the userID is fetched by the session in the JCR implementations, a fallback mechanism is implemented in the Silverpeas LoginModule for JCR to allow the userID to be figuring out by the session. In the Silverpeas wrapper of Oak, the userID is set at authentication and identification success through an AuthInfo object. The userID is the unique identifier of the user in Silverpeas. The JCR system user is the virtual Silverpeas system user (id -1). - Define an access controller for the JCR and this for whatever the implementation of the JCR used. Because, in the JCR, the access rights of the users and of the group of users, the authorization policies (ACL, ...) are defined in the content tree of the JCR, the implementations expect to find the data required to figuring out the privileges of the user as well as the permissions of the user on the accessed node directly from the JCR. But in Silverpeas access rights aren't stored in the JCR and to avoid a deduplication of the authorization mechanism between the JCR and Silverpeas, an access controller is defined with a simple rule of control, as it expects the control has been actually done by the AccessController objects during the navigation of the user in Silverpeas. So, each implementation of the JCR should use this simple access controller to perform their authorization checking. Implement for Oak a PermissionProvider and a TreePermission classes in which the control of access rights on the items in the JCR is performed as it was previously in Silverpeas by the project Silverpeas-JCR-AccessControl project. The access control is actually performed by the SilverpeasTreePermission instances. The SilverpeasPermissionProvider objects delegates the control to these instances. The implementation of the TreePermission extends the access controller presented above. - Add WebDAV support to access documents in the JCR. This support was taken from Silverpeas-Core and adapted to this library. The WebDAV support is based upon the WebDAV JackRabbit implementation. A Link is done between an access token generated for the user accessing a document by WebDAV and his API token to ensure the authentication works fine. This is done transparently. The lock token generation in Oak is broken. It generates the token from the path of the accessed node in the JCR and as such the path contains problematic characters like the separator '/'. See https://issues.apache.org/jira/browse/OAK-10166 A workaround of this issue is to wrap the incoming HTTP request in order to fix the token sent back by the WebDAV client so that the token value is the expected one by Oak. - Add unit tests: * on the Oak repository configuration loading * on the authentications applied by the different * on the Oak repository login mechanism * on the creation of an Oak repository. For the tests, the repository is based upon a memory storage for the data * on the use of MongDB as storage for Oak.
Remove getToken() from the User interface for safety reason. Additional exception catching in DocumentConverter#buildHistorizedDocument
Fixing the workround written about the lock token generation in Oak by taking into account all the encoded characters. See https://issues.apache.org/jira/browse/OAK-10166 Adding into CORE-API a common implementation of a background process in charge of running a Runnable implementation. Implementing a mechanism in charge of executing garbage collection processing which takes also into account the backup files created into the segment store. Two new dedicated parameters are handled: * `segment.compaction.cron`: allows to schedule the processing * `segment.compaction.backup.age`: allows to delete backup files If compaction is enabled, the garbage collection is performed at server start. According to the CRON parameter, the garbage collection processing can also been scheduled. Implementing a logger dedicated to the garbage collection processing. Using the identifier of the JCR_CONTENT node for external services, like a WOPI one.
When refactoring the authentication code, a bug was by inadvertence introduced: when the control is sent back to Silverpeas with an empty login, an unexpected error was thrown because the login has to be non-empty when the authentication process is really performed. Now, the login is checked before any authentication process.
Remove wrappers that were written just to handle the closing of resources allocated when creating a node store for the repository. A ResourceCloser has been written to handle the closing of these resources when Silverpeas is in shutdown. Fix a bug in the versioning handling in Silverpeas. In Apache Jackrabbit 2, the base version in the history of a versioned node is handled differently than in Apache Jackrabbit Oak. In Oak the base version refers always the latest version of a versioned node and it is referenced by the node itself. Hence, it is required to delete this reference either by deleting the node or by removing the versionable mixin from it before any purge of the version history. Rename: - DocumentRepository#lock to DocumentRepository#checkout - DocumentRepository#unlock to DocumentRepository#checkin - DocumentRepository#unlockFromContentDeletion to DocumentRepository#checkinFromContentDeletion Fix the environment test with SilverTestEnv regarding the use of TestBeanContainer by ServiceProvider. Latter uses a thread cache for singleton but this thread cache were cleared only before the execution of a test instead of just once the test instance is created.
Making DocumentConverter be overridden to manage additional stuffs when detecting an versioned document with a broken history. This allow some JCR specific tools handling a such document. DocumentRepository constructors have been implemented in the same goal of DocumentConverter. The constructors allows alternative implementations of DocumentRepository to override DocumentRepository by specifying an overridden implementation of DocumentConverter. URLUtil takes in charge a special case of URL decoding where URLDecoder.decode method have to be applied several times to get the full decoded URL.
Making DocumentConverter be overridden to manage additional stuffs when detecting an versioned document with a broken history. This allow some JCR specific tools handling a such document. DocumentRepository constructors have been implemented in the same goal of DocumentConverter. The constructors allows alternative implementations of DocumentRepository to override DocumentRepository by specifying an overridden implementation of DocumentConverter. Adding robustness into document deletion method by deleting first the document node into the JCR and then deleting the physical content from Silverpeas's workspace. URLUtil takes in charge a special case of URL decoding where URLDecoder.decode method have to be applied several times to get the full decoded URL. About WebDav, allowing the user that is editing the document to unlock technically the WEBDAV content when editing the document with an office editor whereas an other editor instance has already locked the WEBDAV content.
Kudos, SonarCloud Quality Gate passed! |
Merged. |
Take into account the JCR implementation is now brought by a lib and not anymore by a JCA.
The following PRs require to be integrated before this one:
The following PRs require to be integrated after this one: