First of all you should not manipulate the database manually while OpenMeetings is running. OpenMeetings is using frameworks like openJPA to access the database. Those frameworks generate caches based on SQL queries with the effect that data that is accessed often is not loaded from the database but from the cache. Or for example is uses a query cache.
But the second thing is that integration via SOAP should not require to modify any passwords at all. As you generate hash's and add a specific externalUserId to each hash, OpenMeetings will automatically generate users and sync with the given credentials in the API call. Actually SOAP/REST generated users have no password set at all, they are not allowed to use the Web UI login for security reasons and as there can be duplicates with the same username when you would allow users to login with the SOAP/REST generated username. Duplicate usernames can for example happen if you integrate two instances of Moodle with the same OpenMeetings server. => The two Moodle instances should user a different value in the param "externalUserType" (http://incubator.apache.org/openmeetings/UserService.html#setUserObjectAndGenerateRoomHash) but they will of course use the same userId and eventually even have same username/emails on both Moodle instances. So if such a user would be allowed to login, which of those user profiles with that username/email should OpenMeetings use at all? OpenMeetings will generate a user profile for each user that logs in based on the given parameters in: http://incubator.apache.org/openmeetings/UserService.html#setUserObjectAndGenerateRoomHash OpenMeetings will identify unique users by the combination of the attributes: externalUserId+externalUserType So theoretically you can integrate an unlimited number of external systems with a single instance of OpenMeetings. Sebastian 2012/9/14 Jacob Gaiski <[email protected]>: > Hello, > > I’m attempting to change a password. I do not see any SOAP calls for such an > event, so I wrote a SQL call. > > My class takes in a string, and hashed it using MD5. > > When I create a new user in the system, say with the password ‘abcd1234’, I > get a unique hash as expected. When I change the password on another account > to ‘abcd1234’, it produces the same hash; just as expected, and changes the > hash – just as expected. > > > However, roughly only 1/10 of the password changes actually allow the user > to login. > > > Is their another table I’m missing? Why would this be? > > -Jake -- Sebastian Wagner https://twitter.com/#!/dead_lock http://www.webbase-design.de http://www.wagner-sebastian.com [email protected]
