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.)

TODO:

• Registering as a user
• User groups
• Editing users

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:

<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"/>

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"/>

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

<!--
   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"
        />

Will end up like

<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"
                />

Logins timeout when the tomcat session expires. Session expiry happens after a specified period of inactivity. In LibraryServlet.java, 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.

<init-param>
  <param-name>session_expiration</param-name>
  <param-value>3600</param-value>
</init-param>