Changeset 37660 for main

Timestamp:

2023-04-13T21:49:38+12:00 (13 months ago)

Author:

anupama

Message:

ModifyUsersDB() had been modified in revision 35333 and important code present in 35298 had not been retained. That code would re-read the groups and other unmodified fields of a user whose other field(s) were being modified, before storing modified and unmodified values back in the userDB. The new code did not persist existing unmodified values, as a result, running ant config-admin from cmdline or through the installer to change the admin password through all but the GS3 web system (or running update-userdb from the cmdline for any user), would clobber the existing values in the userdb for the fields not being modified. DerbyWrapper.modifyUserInfo() also expressly clobbers the groups field unless the provided groups is null. However, ModifyUsersDB nowadays uses groups = expandGroups(groups) to deal with domain-style groups. Method expandGroups(groups) never returns null, only empty string at minimum, so this would not have fixed the issue either. I still don't know what route the GS3 web system is taking for setting the password, but it did not clobber the groups field at least. However, I've made the minimum number of changes I think necessary to get the ModifyUsersDB.java part of the code (used by ant config-admin/ant update-userdb) to work again.

File:

• main/trunk/greenstone3/src/java/org/greenstone/gsdl3/util/ModifyUsersDB.java (modified) (1 diff)

main/trunk/greenstone3/src/java/org/greenstone/gsdl3/util/ModifyUsersDB.java

@@ -183 +183 @@
     }
 
-  public static void modifyUser(DerbyWrapper dw, UserTermInfo user, String username, String password, String groups, String addgroups, String accountstatus, String comment, String email) {  
-                   
+  private static void modifyUser(DerbyWrapper dw, UserTermInfo user, String username, String password, String groups, String addgroups, String accountstatus, String comment, String email) {
+
+      // Copied code back from svn rev=35298 into this function, as without it, modifying users/admin pwd
+      // wiped out rest of its details from userdb. Notably groups, as groups below now needs to be null
+      // for code to read groups' values back in from db
+      if (groups.equals(""))
+    {
+        // groups should be expandedGroups because we no longer store the groups in userDB
+        // as user-entered or compacted, but as programmatically expanded.
+        // This allows HttpServletRequest.isUserInRole() to now automatically retrieve the
+        // expandedGroups list of a user to check collectionConfig.xml security elements against.
+        
+        groups = user.getExpandedGroups(); // get from database
+    } //else {
+    //groups = UserTermInfo.expandGroups(groups); // ensure groups are stored expanded in userDB
+    //} // Covered: groups var comes in expanded when called from ModifyUsersDB.java::main()
+    // Only should be done if anyone else can call this modifyUser() function and if they don't ensure
+    // groups expanded first
+    // in case any of fields other than username are not specified, get fallbacks from the database
+    
+
+      // groups can never be null at this point if called by ModifyUsersDB.java::main() above,
+      // as main() does groups=expandGroups() which never returns null, only "" at minimum.      
     if (groups == null && addgroups != null) {
       groups = user.getExpandedGroups(); // get the groups from db, as we want to add on to what is already there
     }
+
+    if (password.equals(""))
+    {
+        password = user.getPassword(); // already stored hashed-and-hexed in DB
+    }
+    
+    if (accountstatus.equals(""))
+    {
+        accountstatus = user.getAccountStatus().equals("") ? "true" : user.getAccountStatus();
+    }
+    if (comment.equals(""))
+    {
+        comment = user.getComment();
+    }
+    if (email.equals(""))
+    {
+        email = user.getEmail();
+    }
+    
     if (addgroups != null) {
       if (!groups.equals("")) {