Greenstone Wiki

This page is read only. You can view the source, but not change it. Ask your administrator if you think this is wrong.
====== Greenstone 3 User Management ======

Greenstone software comes equipped with a system for registering and administering users. Greenstone users can register as a user with a login and password. Administrators can then assign them into various groups. These user groups are used for authenticating login to a [[en:user_advanced:remote_greenstone| remote Greenstone server]], and for [[en:user_advanced:security|password protecting collections and documents]], and for access to [[en:user_advanced:web_editor|online document editing]].

(Note, The greenstone 2 version of this page can be found [[en:user_advanced:gs2_user_management|here]].)

The user DB (a derby database) can be found at greenstone3/web/etc/usersDB.

===== User Registration =====
A user can register herself by visiting
http://host:port/greenstone3/library/admin/Register
This is linked to near the bottom of the default library home page. 

Admin can register a new user by visiting the admin page: http://host:port/greenstone3/library/admin/ListUsers, then clicking the 'Add A New User' button.

===== User Groups =====

Groups are used to determine what functionality a user is provided. Multiple groups are specified in a comma-separated list.

**administrator** - can do user management\\
**all-collections-editor** - can edit any collection (through web editing or through remote GLI)\\
**personal-collections-editor** - the user can create their own collections and edit them\\
**<collname>-collection-editor** - the user can edit the <collname> collection\\

Bespoke groups can be added then used in security elements in individual collections, thereby restricting access to only a subset of users. See the [[en:user_advanced:security| Security in Greenstone Collections]] page.
===== Command line editing of users =====

**ant config-admin** - reset the admin password\\
**ant config-user** - add or edit users. This requires you to provide all user fields: username, password, groups, status, comment, email. They can be left blank, but it will override any previous values in the db.

Or you can directly use the java class.\\
Make sure you have set up the Greenstone environment by running **source gs3-setup.sh** (linux/Mac) or **gs3-setup.bat** (windows). Also, start the derby server if its not already running:  **ant start-derby**. if Greenstone is running, then the derby server will be running.

<code>
java org.greenstone.gsdl3.util.ModifyUsersDB 
Usage: java org.greenstone.gsdl3.ModifyUsersDB <full_path_of_the_usersDB> <username|ALL> [-noAdd] 
[password=pwd] [groups=grp] [addgroups=grp] [accounstatus=status] [comment=cmt] [email=address]
</code>

(Options valid for releases from September 2021)

Eg: To add a new user
<code>java org.greenstone.gsdl3.ModifyUsersDB <path-to-greenstone3>/web/etc/usersDB kath password=changeme groups=student</code>

The **groups** option will set the group field to the specified value.\\
The **addgroups** option will add the specified groups to whatever groups exist already (if editing an existing user)

Using username **ALL** will perform the selected changes on all users.\\
For example, to add the 'student' group to all users, run

<code>java org.greenstone.gsdl3.ModifyUsersDB <path-to-greenstone3>/web/etc/usersDB ALL  addgroups=student</code>

The **-noAdd** option will **not** create a new user if the specified username does not exist.

==== Viewing and Editing the database via a text file ====

There are 2 java programs which help you view and edit the database: usersDB2txt and txt2usersDB
As above, you must set up the greenstone environment, and make sure the derby server is running.

They are run like:
<code>
java org.greenstone.gsdl3.util.usersDB2txt <path-to-gs3>/web/etc/usersDB >& usersDB.txt

... edit the file if necessary, then regenerate the DB:

java org.greenstone.gsdl3.util.txt2usersDB usersDB.txt <path-to-gs3>/web/etc/usersDB [-append]
</code>
The **-append** option means append the contents of the file into the DB. Without it, the current contents will be deleted.

==== Setting up the Recaptcha test for User Registration ====

**NOTE:** this applies to Greenstone 3.09 and later (3.09 nightly releases from September 2018).

Greenstone 3 is set up to use Recaptcha for authenticating users when they are registering. Recaptcha requires a public "site" key, and a private "secret" key. Greenstone is shipped with Google's testing keys, which always validate. You will need to generate your own key pair at [[https://www.google.com/recaptcha/admin]] and enter them into the web/sites/localsite/siteConfig.xml file:

<code>
<recaptcha name="site_key" value="6LeIxAcTAAAAAJcZVRqyHh71UMIEGNQ_MXjiZKhI"/> 
<recaptcha name="secret_key" value="6LeIxAcTAAAAAGG-vFI1TnRWxMZNFuojJ4WifJWe"/>
</code>

By default, Greenstone is set up to use the recaptcha test for the "register" and "adduser" operations. If you would like to add it to other operations (or remove it from the current ones) please edit the operations recaptcha element in siteConfig.xml:
<code>
<!-- edit this list to specify which operations use the recaptcha test-->
<!-- valid operations include Register, AddUser, Login, -->
<recaptcha name="operations" value="Register,AddUser"/>
</code>

Note: please restart Tomcat for these changes to take effect.
=== Disabling Recaptcha in earlier versions of Greenstone ===

Prior to 3.09 Greenstone used version 1 of recaptcha, which is no longer supported by Google. If you have an older Greenstone, you will not be able to use recaptcha any more (unless you update your Greenstone to 3.09 or later, or a nightly release). Please remove the following two recaptcha lines in the web/sites/localsite/siteConfig.xml file:
<code>
<recaptcha name="public_key" value="6LckI88SAAAAACUYjj97WMcnz5HPjVp3lI-x-ue8"/> 
<recaptcha name="private_key" value="6LckI88SAAAAAGnGy1PwuXYZzIMXZYoPxN51bWWG"/>
</code>

===== GS3 Tomcat authentication notes =====

We use Tomcat Realm to connect to JDBC database of users. Its specified in
resources/tomcat/greenstone3.xml.in (which gets copied to resources/tomcat/context-name.xml, and then to packages/tomcat/conf/Catalina/localhost/context-name.xml

<code>
<!--
   For embedded derby db:
   driverName="org.apache.derby.jdbc.EmbeddedDriver"
   connectionURL="jdbc:derby:@gsdl3webhome@/etc/usersDB"
-->  
<Realm className="org.apache.catalina.realm.JDBCRealm" 
        driverName="org.apache.derby.jdbc.ClientDriver"
        connectionURL="jdbc:derby://@derbyserver@:@derbyserverport@/@gsdl3webhome@/etc/usersDB"
        userTable="users" userNameCol="username" userCredCol="password"
        userRoleTable="roles" roleNameCol="role"
        />
</code>

Will end up like

<code>
<Realm className="org.apache.catalina.realm.JDBCRealm" 
        driverName="org.apache.derby.jdbc.ClientDriver"
        connectionURL="jdbc:derby://localhost:1527//greenstone/greenstone3/web/etc/usersDB"
        userTable="users" userNameCol="username" userCredCol="password"
        userRoleTable="roles" roleNameCol="role"
                />

</code>

Logins timeout when the tomcat session expires. Session expiry happens after a specified period of inactivity. In LibraryServlet.java, have 
<code>
/**
  * the maximum interval that the cached info remains in session_ids_table
  * (in seconds) This is set in web.xml
  */
  protected int session_expiration = 1800;

</code>

This can be overridden by putting a session-expiration init-param into your servlet specification in web/WEB-INF/servlets.xml (which is included by web.xml). This is specified in seconds.
<code>
<init-param>
  <param-name>session_expiration</param-name>
  <param-value>3600</param-value>
</init-param>
</code>