Ok, good -- glad the fix worked for you. And yes, I agree, setMyProfile() is probably a better name for the UserManager method. :)

UserDatabase.commit(), by the way, was deprecated a while ago. It does nothing. We have retained it for backwards compatibility, though. (All of this is in the Javadocs...)

Andrew


On May 6, 2008, at 9:40 AM, Terry Steichen wrote:

Replying to my own post - the problem I encountered was caused by the
fact that, as I earlier said I suspected, the new version of
UserManager.setUserProfile() was indeed changed in 2.6.2.  That method
would now more accurately be called UserManager.setMyProfile() because
it assumes that the profile being set is that of the current logged in
user. I suspect that was the implicit assumption all along, but was not
made explicit until 2.6.2 (or thereabouts).  That is why my use of it
worked fine until 2.6.2.

My fix (briefly tested) was simple - looking at the pseudocode below, I simply commented out the call to UserManager.setUserProfile(); I already
do the permission and name checks, so that method was actually
superfluous for my use.

However, I do still note that there is no 'commit' for the userdatabase changes included in the present version of UserManager.setUserProfile().
Not sure if that's a bug or not.  [Andrew?]



On Mon, 2008-05-05 at 16:32 -0400, Terry Steichen wrote:

I've got a module which, when passed a new loginname by a visitor,
authenticates itself as an admin user, creates a new account for the
user, and e-mails a new password to that user. It's been working well
for a year or more through several previous versions.  It works
perfectly with 2.4.104.  (I just re-verified it again.)

However, under 2.6.2 what this module appears to be doing is, rather
than creating a new user, it's renaming the admin user to the name
submitted by the visitor, and changing the admin user's password to the newly generated one (and of course, e-mailing that to the visitor, who
now becomes admin!)

My module's logic is simple; pseudocoded (minor details removed for
clarity) it is roughly as follows:

       wikiSession = WikiSession.guestSession(wiki);
       try {

               if(wiki.getAuthenticationManager().login(wikiSession,
               admin_name, admin_pass) == true) {

                       UserManager manager = wiki.getUserManager();
                       UserProfile profile =
                       manager.getUserDatabase().newProfile();

                       profile.setLoginName( lname );
                       profile.setEmail( email );
                       profile.setFullname( fname );
                       profile.setPassword( pwd );
                       profile.setWikiName( wname );

                       manager.setUserProfile(wikiSession,profile);
                       manager.getUserDatabase().save(profile);
                       manager.getUserDatabase().commit();

       }
       } catch (Exception e) {

System.out.println("Error in login - "+e.getMessage());

       } finally {

               wikiSession.invalidate();

       }

Now, I realize this isn't the way that UserManager is normally used.
But I don't frankly see any logical reason you shouldn't be able to do
it this way.

My suspicion is that the new feature recently added - to rename users -
is causing some different internal behavior.  I did a little initial
poking around UserManager.setUserProfile(), I notice that there has
indeed been a rename function inserted into this method. (I also notice
that the call to getUserDatabase().commit is missing in 2.6.2.

I hope that someone who understands the logic of this process can give
me a hand in understanding the changes.






Reply via email to