14 October 2009, 1:09

Hi we have got development, test and production environment. Now, in DEV environment we implemented Mahoodle and is working fine.

While trying to implement this in TEST I encountered significant problems. When user was landing on Mahara from Moodle then the following standard error message was appearing.

Sorry, could not log you in :(

  And in error log of Mahara I found following things...

[WAR] bd (api/xmlrpc/client.php:167) Unknown error occured: 7023: [[encryption-invalid]], referer: http://moodle.site.edu.au/
Call stack (most recent first):, referer: http://moodle.site.edu.au/

* Client->send("http://moodle.site.edu.au/ ") at /var/eport/auth/xmlrpc/lib.php:117, referer: http://moodle.site.edu.au/

* AuthXmlrpc->request_user_authorise("f95b8a2f51550d2d6cec65e245782e8ed2e74490", "http://moodle.site.edu.au/ ") at /var/eport/auth/xmlrpc/land.php:95, referer: http://moodle.site.edu.au/

I deleted both public keys of Mahara and Moodle then tried deleting peer in Moodle and XMLRPC instance in Mahara. This didn't solve any problems.

Later on while investigating this I found that in Mahara database there is a host table. There is an entry for Moodle host with all details. But when you remove XMLRPC instance from institution, it should be deleted. But it just stays there.

Even after deleting the XMLRPC instance when you add new XMLRPC instance it should update or make new entry in this table. But instead of this the old entry remained same and no new entry for added XMLRPC instance Strange!

At Moodle site the public key was renewed and it doesn't get reflected in Mahara's host table even after you delete and add XMLRPC instance again. 

I am afraid that this is a bug as not deleting the host entry when you remove XMLRPC instance. And when you add it and use it for the same Moodle wwwroot then mahara uses that old host entry for this XMLRPC instance without re-fetching the key from Moodle site.

After manually deleting the host entry when I re-added the XMLRPC instance in Institution then all details about this in host table were new and updated. Thereafter, Mahoodle worked like a charm in TEST environment.

Please, verify about this and I believe most of the people who have encountered this sort of errors may be are the victim of this bug.

14 October 2009, 21:04

Hi,

Did you migrate from dev to test by copying the database/dataroot? If that was the case, you were always going to have to delete your public/private keys for Moodle and Mahara. Those keys are generated for a given wwwroot, so moving wwwroots will always break them.

This is actually a problem in itself - we should be telling admins when the key is busted.

From what I remember of the original MNET decisions, the host record isn't deleted because you could always have two or more XMLRPC plugins for the same host. The actual way you should be rotating keys is by deleting the Moodle key on the Moodle side and the Mahara key on the Mahara side - that will trigger keyswap to happen the next time they connect. The problem with this is that it's hard to delete the key on the Mahara side (you have to go into the database to do it). And I'm not convinced it'll work properly anyway if the old keys are no longer valid 

It would probably make sense if we deleted the host table's row if the last XMLRPC authinstance for that host was deleted. In 99% of cases, that means the host row will be deleted, and thus help you out.

Could you please file a bug report about this, and link to this thread? It's something we should consider for sure  

14 October 2009, 23:25

Hi, I have filed a bug report for this.

Another thing about duplication of account when user jump from Moodle to Mahara. In our Moodle implementation email address is locked. While in Mahara email addresses are not locked.

Now consider one thing, when user have changed their email address in Mahara and they jump from Moodle to Mahara. If Mahara admin have enabled the Update user info flag in XMLRPC auth then this email address is updated. In this way user loose their preferred email address if set different than moodle.

And if the Update info flag is not enabled than Mahara counts the user as new user even Parent Auth Instance is LDAP (same for Moodle) . Then duplicate account is created. I have tried these things (new installation) and exactly happening with us.

I think this needs to be addressed. While I was implementing Update user info flag for LDAP auth instance I came across same sort of thing and I opted out email address from that.  If you remember the issue while I created this feature.

[edit by nigel: fixed your bug report link which was broken] 

15 October 2009, 23:03

Thanks for filing that bug report. I am going to make some time next week to have a look at the MNET bugs in the tracker, and see if I can get some of them squashed. That includes the duplication of account problem. I think Richard Mansfield may have fixed it on master already (in which case the fix will be in Mahara 1.2), but I'll check again.

Also next week, I will test your LDAP patch, and get that included if it works. 

21 October 2009, 1:10

Hi I tried the same thing using Mahara 1.2.0.beta4 and found duplication of account is happening.

But after inserting $cfg->usersuniquebyusername this is not happening more. Also I need to enable Allow Multiple Institutions ? Even I tried this with Mahara 1.1.5 which is our exsiting implementation.

The question is in Mahara 1.20.beta4 the provision for  $cfg->usersuniquebyusername in site administration is missing. It should have to be there.

 

 

22 October 2009, 1:52

Hi - annoying that you're getting the duplication in 1.2 beta 4 - that should not be happening. I'm going to investigate this with my setup, when I come to test out some of these MNET related bugs (and your LDAP patch), which should I plan to do today or tomorrow.

As for that setting, it's in the config.php file for a very good reason - it's a very dangerous setting to turn on unless you know what you're doing. It's not even in config-defaults.php for this reason.  Here's the comment in the code where it's used:

                 // When turned on, this setting means that it doesn't matter 

                // which other application the user SSOs from, they will be 

                // given the same account in Mahara.

                //

                // This setting is one that has security implications unless 

                // only turned on by people who know what they're doing. In 

                // particular, every system linked to Mahara should be making 

                // sure that same username == same person.  This happens for 

                // example if two Moodles are using the same LDAP server for 

                // authentication.

                //

                // If this setting is on, it must NOT be possible to self 

                // register on the site for ANY institution - otherwise users 

                // could simply pick usernames of people's accounts they wished 

                // to steal.

Anyway, I'll test out some of these MNET related issues soon and update all the bug reports.

27 October 2009, 1:06

I have just tried, and it seems that Richard has fixed the account duplication issue in both master and 1.1_STABLE, so the fix will be in 1.1.7 and 1.2. The fix was definitely applied before the beta was released, so I'm not sure why you would still be seeing the issue - if you had marked the LDAP auth method as the parent of the XMLRPC one, you shouldn't get any more dupes from new users at least.

27 October 2009, 18:55

Yes Richard's patch works but after making an entry for  'usersuniquebyusername', '1'  in config table.

 I have  tried same thing with new installation of Mahara Beta 4 and same thing. No provison to enable the above flag through Mahara Interface nor any entry in config table. I did it manually through SQL.

Richard's patch will work only if above flag is set and multiple instituion is enabled.

In our implemenation LDAP auth method is parent.

 

 

27 October 2009, 20:59

That's strange - if your servers were accessible by ssh, I'd be tempted to ask to have a poke around inside them and see exactly what that is the case - because the patch definitely shouldn't need that flag.

Any chance of getting access, or is that impossible? 

27 October 2009, 22:20

Ohh sorry nigel but not possible.....

But the things that I described are exactly happening...see below the code it says if config is set ! ?

/auth/xmlrpc/lib.php....

 // Retrieve a $user object. If that fails, create a blank one.
        try {
            $user = new User;
            if (get_config('usersuniquebyusername')) {
                // When turned on, this setting means that it doesn't matter
                // which other application the user SSOs from, they will be
                // given the same account in Mahara.
                //
                // This setting is one that has security implications unless
                // only turned on by people who know what they're doing. In
                // particular, every system linked to Mahara should be making
                // sure that same username == same person.  This happens for
                // example if two Moodles are using the same LDAP server for
                // authentication.
                //
                // If this setting is on, it must NOT be possible to self
                // register on the site for ANY institution - otherwise users
                // could simply pick usernames of people's accounts they wished
                // to steal.
                if ($institutions = get_column('institution', 'name', 'registerallowed', '1')) {
                    log_warn("usersuniquebyusername is turned on but registration is allowed for an institution. "
                        . "No institution can have registration allowed for it, for security reasons.\n"
                        . "The following institutions have registration enabled:\n  " . join("\n  ", $institutions));
                    throw new AccessDeniedException();
                }

                if (!get_config('usersallowedmultipleinstitutions')) {
                    log_warn("usersuniquebyusername is turned on but usersallowedmultipleinstitutions is off. "
                        . "This makes no sense, as users will then change institution every time they log in from "
                        . "somewhere else. Please turn this setting on in Site Options");
                    throw new AccessDeniedException();
                }

                $user->find_by_username($remoteuser->username);
            }
            else {
                $user->find_by_instanceid_username($this->instanceid, $remoteuser->username, true);
            }