User Tools

Site Tools


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 remote Greenstone server, and for password protecting collections and documents, and for access to online document editing.

(Note, The greenstone 2 version of this page can be found 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 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 (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.

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]

(Options valid for releases from September 2021)

Eg: To add a new user

java org.greenstone.gsdl3.ModifyUsersDB <path-to-greenstone3>/web/etc/usersDB kath password=changeme groups=student

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

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

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:

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]

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 and enter them into the web/sites/localsite/siteConfig.xml file:

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

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:

<!-- edit this list to specify which operations use the recaptcha test-->
<!-- valid operations include Register, AddUser, Login, -->
<recaptcha name="operations" value="Register,AddUser"/>

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:

<recaptcha name="public_key" value="6LckI88SAAAAACUYjj97WMcnz5HPjVp3lI-x-ue8"/> 
<recaptcha name="private_key" value="6LckI88SAAAAAGnGy1PwuXYZzIMXZYoPxN51bWWG"/>

GS3 Tomcat authentication notes

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

   For embedded derby db:
<Realm className="org.apache.catalina.realm.JDBCRealm" 
        userTable="users" userNameCol="username" userCredCol="password"
        userRoleTable="roles" roleNameCol="role"

Will end up like

<Realm className="org.apache.catalina.realm.JDBCRealm" 
        userTable="users" userNameCol="username" userCredCol="password"
        userRoleTable="roles" roleNameCol="role"

Logins timeout when the tomcat session expires. Session expiry happens after a specified period of inactivity. In, have

  * 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;

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.

en/user_advanced/gs3_user_management.txt · Last modified: 2023/03/13 01:46 by