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

TODO:
  * Registering as a user
  * User groups
  * Editing users

==== 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>
=== 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>