Ideas and suggestions for an OpenKM Instance-Manager needed!

[Sascha]

Hey together,

today I am searching hints, ideas and in best case some samples for a needed implementation. I tried to describe the scenario with some text and an sketch.

Description:

By default the user is accessing the default openkm-(jboss)-instance by using the login-form. In case of more instances on one servermachine, the same user has to login several times. If there are 4 instances, the user has to login on every instance. Also the user has to search in every instance for a relevant project. In such a case an Instance-Manager would be perfect. The login will be made on the default-instance (jboss-instance #1). If the login is correct the script queries the other jboss-instances by the username and password. If the authentication is ok, the roles of every affected instance will be collected in an array. The roles are used to identify the project-directory. Every directory under root is an project an has an specific role. When the script collects all roles from every jboss-instance, this project-roles will be listed in a selectionbox like the language selectionbox. The user can now choose the needed project an will be forwarded to the right instance directly without an second authentication.

I tried it already with an extern web application out of openkm in php. The instances can be queried by the webservices and the forwarding can be realised simply with javascript. The only problem is that the automated authentication without standard login-form is an problem and difficult to solve. Now I try to use the java-environment on the servermachine java.

First questions:
1. What type of implementation is recommended to extend the login-form?
2. Is this the right attempt or are there better, simplier ways that I didn´t see?
3. How can I realize the automated authentication on the other jboss-instances?

See also the attachment. I hope the explanation is coherent.

Thx
Sascha

[jllort]

Something experimental we've done is a specific spring authentication class based on webservices. That allows us authenticate across OpenKM with webservices and also capture the password and hold into session to reuse it. I think something in this way could help you.

This configuration is an approximation of what we got in professional version -> tenant. There's only one instance what into has several tenants. The only limitation we got in that scenario is that one user only can access to one tenant. I think there's a problem with tenant and workspace definition. For our point of view one user should only get access to one tenant. But could be several workspaces on same tenant ( like okm:root ). The idea we got in mind is implementing a feature to be able to create other workspaces ( okm:workspace1 etc... ) and provide access to the users.

We think tenant is good idea for small or medium repositories but not for huge, where we think could be better separate in several servers. In your configuration you got several OpenKM running, that mean consuming more hardware resources than get only one ( also maintenance operations like backup etc. are a factor to take in consideration ).

Your feedback is welcome.

[Sascha]

Hey jllort, thank you for the extensive explanation. I will try to solve it with the session and reuse the authentication. Multitenancy is a okm professional feature, right? That is really interesting.

What do you think about that idea. The main instance loads repository-parts that match the role "testproject_x" from the other instances over webservices (f.e. like the joomla explorer). Maybe scripts could check every single instance automatically.

The single projects would be aggregated under "Taxonomy" or "My Documents". Is this technically possible?

Best regards

[jllort]

The question is not if it's possible or not ( I think it is ). The question is if it's good idea, and maintance is not a problem. Using webservices you can build layer at top what can take control of each repository and do some operation is several repositories at same time. If operations are simply ( your bussiness logic ) I think there's no problem. But if you should run away complex logic.

Other solution, like joomla explorer or like https://www.youtube.com/watch?v=D0M5M-XPXUs is build a minimal UI based on REST services ( I suggest use our SDK ) and with other database ( one table ) indicate what user can switch to repositories etc.... Obviously that has an extra cost, and you'll not get 100% openkm UI features ( you need all ? ) but you can get better UI as your real needs ( look & feel ) and control of user login to each repository. If you decide for it I encourage use one of our SDK to get compatibility on future releases and do less changes between versions http://wiki.openkm.com/index.php/SDK

[Kadivnai]

The problem, as I mentioned in an earlier post, is that the Version class does have a versionId. Here are the attributes in the Version class:

[jllort]

You forgot write the version class attributes ?
Are you talking about Version.java ?

Code: Select all

public class Version implements Serializable {
	private static final long serialVersionUID = 3219672583638952409L;

	private String name;
	private Calendar created;
	private long size;
	private String author;
	private boolean actual;
	private String comment;
	private String checksum;
etc...