Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-12492

Unable to connect 2 moodle servers: RPC auth/mnet/user_authorise:Payload not encryptedERROR 1:1:Payload not encrypted

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.8.3
    • Fix Version/s: None
    • Component/s: MNet
    • Labels:
      None
    • Affected Branches:
      MOODLE_18_STABLE

      Description

      RPC auth/mnet/user_authorise:Payload not encryptedERROR 1:1:Payload not encrypted

      cant connect servers

      any ideas

        Gliffy Diagrams

          Issue Links

            Activity

            Hide
            andreabix Andrea Bicciolo added a comment -

            This problem is starting to widespread: we currently have three Moodle sites out of service due to this issue

            Show
            andreabix Andrea Bicciolo added a comment - This problem is starting to widespread: we currently have three Moodle sites out of service due to this issue
            Hide
            dougiamas Martin Dougiamas added a comment -

            Andrea, were these sites that used to work? Did they break in an upgrade?

            Donal, any suggestions?

            Show
            dougiamas Martin Dougiamas added a comment - Andrea, were these sites that used to work? Did they break in an upgrade? Donal, any suggestions?
            Hide
            dougiamas Martin Dougiamas added a comment -

            Need more info about this. Donal, can it be closed?

            Show
            dougiamas Martin Dougiamas added a comment - Need more info about this. Donal, can it be closed?
            Hide
            donal@catalyst.net.nz Donal McMullan added a comment -

            MD: I believe so but I'd like more feedback from Andrea.

            Show
            donal@catalyst.net.nz Donal McMullan added a comment - MD: I believe so but I'd like more feedback from Andrea.
            Hide
            scyrma Mathieu Petit-Clair added a comment -

            I have two moodle checkouts, on the same server (distinct folders, data directories and databases). Both sites have the same configuration (both are enabled for publish and subscribe).

            On one site, in admin->networking->enrolments, under column courses I see "5 - enrol". Clickin on 'enrol' I get a list of courses available on the other site. Doing the same thing on the other site gives me the error "RPC enrol/mnet/available_courses:ERROR 1:Payload not encrypted".

            On the same first site, I have the "courses" block shown on front page. Clicking on a course available on the second site, I get the error "RPC auth/mnet/user_authorise:Payload not encryptedERROR 1:1:Payload not encrypted" from the second site (so I am "changing site").

            I tried the same thing with a fresh checkout, and both sites are working as expected. I don't know what to think: either some cruft was left over in the database or this is a mandelbug of some sort...

            Show
            scyrma Mathieu Petit-Clair added a comment - I have two moodle checkouts, on the same server (distinct folders, data directories and databases). Both sites have the same configuration (both are enabled for publish and subscribe). On one site, in admin->networking->enrolments, under column courses I see "5 - enrol". Clickin on 'enrol' I get a list of courses available on the other site. Doing the same thing on the other site gives me the error "RPC enrol/mnet/available_courses:ERROR 1:Payload not encrypted". On the same first site, I have the "courses" block shown on front page. Clicking on a course available on the second site, I get the error "RPC auth/mnet/user_authorise:Payload not encryptedERROR 1:1:Payload not encrypted" from the second site (so I am "changing site"). I tried the same thing with a fresh checkout, and both sites are working as expected. I don't know what to think: either some cruft was left over in the database or this is a mandelbug of some sort...
            Hide
            scyrma Mathieu Petit-Clair added a comment -

            I can reproduce this error almost on demand (but not quite)...

            I traced this down to /mnet/xmlrpc/xmlparser.php, line 89, where $data is empty, somehow, sometimes. If data is empty, $this->cipher is obviously empty too, thus breaking the rest of the code. I don't know what's causing $data to be empty there, but there appears to be something saved about it in the database that makes it permanent: if you wipe your tables, then it will work again (data will be received again). Though I don't suggest wiping your tables, as it will break the rest of mnet... (for one thing, you won't be able to replace the public key for your host).

            My (wild) guess is there's a sequence that stuff should be done in ... like if the peer is in "community hub" mode when you first add it, it will work.. but if it's not otherwise prepared to accept this new peer, it won't work. (This sequence is what some documentation recommends, iirc, but if it's this critical, it should really be enforced by the system!)

            This bug is made worse by the fact that it's impossible to really delete a peer.. so you can't really start over (actually, it's more like "nearly impossible" - I'm being told there might be a timeout happening at some point here, after which hosts do disappear for real)

            Show
            scyrma Mathieu Petit-Clair added a comment - I can reproduce this error almost on demand (but not quite)... I traced this down to /mnet/xmlrpc/xmlparser.php, line 89, where $data is empty, somehow, sometimes. If data is empty, $this->cipher is obviously empty too, thus breaking the rest of the code. I don't know what's causing $data to be empty there, but there appears to be something saved about it in the database that makes it permanent: if you wipe your tables, then it will work again (data will be received again). Though I don't suggest wiping your tables, as it will break the rest of mnet... (for one thing, you won't be able to replace the public key for your host). My (wild) guess is there's a sequence that stuff should be done in ... like if the peer is in "community hub" mode when you first add it, it will work.. but if it's not otherwise prepared to accept this new peer, it won't work. (This sequence is what some documentation recommends, iirc, but if it's this critical, it should really be enforced by the system!) This bug is made worse by the fact that it's impossible to really delete a peer.. so you can't really start over (actually, it's more like "nearly impossible" - I'm being told there might be a timeout happening at some point here, after which hosts do disappear for real)
            Hide
            pser2000 Peter Sereinigg added a comment -

            We solved the problem in upgrading php.
            regards Peter

            Show
            pser2000 Peter Sereinigg added a comment - We solved the problem in upgrading php. regards Peter
            Hide
            pser2000 Peter Sereinigg added a comment -

            php update solved the problem

            Show
            pser2000 Peter Sereinigg added a comment - php update solved the problem

              People

              • Votes:
                2 Vote for this issue
                Watchers:
                3 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: