Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Component/s: docs.moodle.org
    • Labels:
      None
    • Rank:
      33505

      Description

      Steps to reproduce:

      1. Login to http://docs.moodle.org/22/en/ as an ordinary user (not an admin)
      2. Go to any unprotected page and click the edit tab

      Rather than being able to edit the page, you are redirected to the log in page (though you remain logged in).

      This problem affects 22/en, 20/en and 19/en (but not 21/en).

        Activity

        Hide
        Eloy Lafuente (stronk7) added a comment - - edited

        Uhm, after a lot of switching here... I can confirm that I'm able to duplicate this constantly, but only under 19/en and 20/en (have not been able to reproduce it at all under 21/en nor 22/en).

        To reproduce:

        1. Logout from some of the offending versions (19 or 20).
        2. Go to the http://docs.moodle.org/OFFENDINGVERION/en/Authentication page
        3. Click on edit, you will be redirected to the login page (it's normal).
        4. Log as normal user (not admin not manager of any type).
        5. You are redirected to the page in 2) above. Verify that you're logged (header of the page)
        6. Click on edit, you are redirected to login again (and it should not happen, because you're logged now).
        Show
        Eloy Lafuente (stronk7) added a comment - - edited Uhm, after a lot of switching here... I can confirm that I'm able to duplicate this constantly, but only under 19/en and 20/en (have not been able to reproduce it at all under 21/en nor 22/en). To reproduce: Logout from some of the offending versions (19 or 20). Go to the http://docs.moodle.org/OFFENDINGVERION/en/Authentication page Click on edit, you will be redirected to the login page (it's normal). Log as normal user (not admin not manager of any type). You are redirected to the page in 2) above. Verify that you're logged (header of the page) Click on edit, you are redirected to login again (and it should not happen, because you're logged now).
        Hide
        Eloy Lafuente (stronk7) added a comment -

        I've tried also some editions in other wikis (19/es, 19/de, dev...) and seems to work properly there too

        So only 19/en and 20/en seem to reproduce the problem constantly.

        I really cannot imagine anything but... perhaps... they are missing some upgrade or any other maintenance script regenerating or refreshing the permissions?

        Or there is something in multi-version wikis making some versions to fail? (uhm, don't think so, because for en, both 22 and 21 are working).

        Really cannot imagine any reason for that constant bad behavior but they missing some upgrade/maintenance script execution.

        Ciao

        Show
        Eloy Lafuente (stronk7) added a comment - I've tried also some editions in other wikis (19/es, 19/de, dev...) and seems to work properly there too So only 19/en and 20/en seem to reproduce the problem constantly. I really cannot imagine anything but... perhaps... they are missing some upgrade or any other maintenance script regenerating or refreshing the permissions? Or there is something in multi-version wikis making some versions to fail? (uhm, don't think so, because for en, both 22 and 21 are working). Really cannot imagine any reason for that constant bad behavior but they missing some upgrade/maintenance script execution. Ciao
        Hide
        Eloy Lafuente (stronk7) added a comment -

        I'm assigning this to Jordan, he knows which versions have been upgrade and/or which maintenance scripts have been executed there, leading to 19 & 20 NOT being editable and 21 & 22 being editable.

        Ciao

        Show
        Eloy Lafuente (stronk7) added a comment - I'm assigning this to Jordan, he knows which versions have been upgrade and/or which maintenance scripts have been executed there, leading to 19 & 20 NOT being editable and 21 & 22 being editable. Ciao
        Hide
        Eloy Lafuente (stronk7) added a comment - - edited

        Ohoh, just discovered this, logged as normal user in 19/en:

        You do not have permission to edit this page, for the following reason:
        Your IP address has been automatically blocked because it was used by another user, who was blocked by Tsala. The reason given is this:
        Autoblocked because your IP address has been recently used by "Denzcasa84".
        The reason given for Denzcasa84's block is: "Spamming links to external sites"
        Start of block: 07:29, 9 December 2011
        Expiry of block: 07:29, 10 December 2011
        Intended blockee: 127.0.0.1
        

        Same for 20/en, lalala, and no block for 21/en nor 22/en.

        So, now, my bet is about the recently installed Vanish proxy... running in the same machine... and not passing the 'x-forwarded-for' header leading to global edition blocks, hoho.

        Surely easy to fix, just enforce Vanish to pass it on all requests (http close) and done (I hope).

        Ciao

        Show
        Eloy Lafuente (stronk7) added a comment - - edited Ohoh, just discovered this, logged as normal user in 19/en: You do not have permission to edit this page, for the following reason: Your IP address has been automatically blocked because it was used by another user, who was blocked by Tsala. The reason given is this : Autoblocked because your IP address has been recently used by "Denzcasa84" . The reason given for Denzcasa84's block is: "Spamming links to external sites" Start of block: 07:29, 9 December 2011 Expiry of block: 07:29, 10 December 2011 Intended blockee: 127.0.0.1 Same for 20/en, lalala, and no block for 21/en nor 22/en. So, now, my bet is about the recently installed Vanish proxy... running in the same machine... and not passing the 'x-forwarded-for' header leading to global edition blocks, hoho. Surely easy to fix, just enforce Vanish to pass it on all requests (http close) and done (I hope). Ciao
        Hide
        Eloy Lafuente (stronk7) added a comment -

        In the mean time, I think you can avoid using the temporary "Automatically block the last IP address used by this user, and any subsequent IP addresses they try to edit from" for those blocks. That will allow 127.0.0.1 (aka, everybody else) to continue editing.

        Note that such IP block is a temp one (1 day only) done to prevent the same IP to connect as another user).

        So, surely the "temp-ip" lock above is already expired and 19/en is working ok no (until a new block is done with that checkbox enabled).

        Ciao

        Show
        Eloy Lafuente (stronk7) added a comment - In the mean time, I think you can avoid using the temporary "Automatically block the last IP address used by this user, and any subsequent IP addresses they try to edit from" for those blocks. That will allow 127.0.0.1 (aka, everybody else) to continue editing. Note that such IP block is a temp one (1 day only) done to prevent the same IP to connect as another user). So, surely the "temp-ip" lock above is already expired and 19/en is working ok no (until a new block is done with that checkbox enabled). Ciao
        Hide
        Jordan Tomkinson added a comment -

        OK, the problem here is that we now use Varnish cache infront of Mediawiki.
        Mediawiki will see ALL users come from the IP 127.0.0.1, so if you ban the IP you will ban ALL users.

        I configured MediaWiki as per the Varnish docs at http://www.mediawiki.org/wiki/Manual:Varnish_caching specifically the option $wgSquidServers which tells MediaWiki to ignore the clients IP and instead use the X-Forwarded-For HTTP header, which has the correct remote client IP address.

        As this is obviously not happening - it's possible that the ban function is not aware of the X-Forwarded-For header, or something else is going wrong..

        This needs investigation for sure

        Show
        Jordan Tomkinson added a comment - OK, the problem here is that we now use Varnish cache infront of Mediawiki. Mediawiki will see ALL users come from the IP 127.0.0.1, so if you ban the IP you will ban ALL users. I configured MediaWiki as per the Varnish docs at http://www.mediawiki.org/wiki/Manual:Varnish_caching specifically the option $wgSquidServers which tells MediaWiki to ignore the clients IP and instead use the X-Forwarded-For HTTP header, which has the correct remote client IP address. As this is obviously not happening - it's possible that the ban function is not aware of the X-Forwarded-For header, or something else is going wrong.. This needs investigation for sure
        Hide
        Jordan Tomkinson added a comment -

        Doh, $wgSquidServers was typed incorrectly in LocalSettings.php and thus was invalid.
        I have corrected the problem and will now proceed to unban all instances of 127.0.0.1
        sorry all

        Show
        Jordan Tomkinson added a comment - Doh, $wgSquidServers was typed incorrectly in LocalSettings.php and thus was invalid. I have corrected the problem and will now proceed to unban all instances of 127.0.0.1 sorry all
        Hide
        Eloy Lafuente (stronk7) added a comment - - edited

        Yay, thanks Jordan!

        PS: I've backported your last 2 commits to REL1_17_private (aiming to stop using MDLSITE-1511_deploy some day when everything is stable and we can agree the way to go after that)

        Show
        Eloy Lafuente (stronk7) added a comment - - edited Yay, thanks Jordan! PS: I've backported your last 2 commits to REL1_17_private (aiming to stop using MDLSITE-1511 _deploy some day when everything is stable and we can agree the way to go after that)
        Hide
        Helen Foster added a comment -

        Sorry for needing to reopen this issue, however I've just tried blocking a user in http://docs.moodle.org/20/en then logging in as an ordinary user. I was again unable to edit pages, instead being redirected to the log in page.

        Show
        Helen Foster added a comment - Sorry for needing to reopen this issue, however I've just tried blocking a user in http://docs.moodle.org/20/en then logging in as an ordinary user. I was again unable to edit pages, instead being redirected to the log in page.
        Hide
        Jordan Tomkinson added a comment -

        Can you please try it again Helen, i have updated the proxy config further.
        MediaWiki's documentation is not very explicit about how things need to be setup. hopefully this time I have everything covered

        Show
        Jordan Tomkinson added a comment - Can you please try it again Helen, i have updated the proxy config further. MediaWiki's documentation is not very explicit about how things need to be setup. hopefully this time I have everything covered
        Hide
        Helen Foster added a comment -

        Thanks for trying Jordan, however the problem remains. (Just tried in the 20/en wiki.)

        Show
        Helen Foster added a comment - Thanks for trying Jordan, however the problem remains. (Just tried in the 20/en wiki.)
        Hide
        Jordan Tomkinson added a comment -

        I have spoken to Eloy he is going to look at the code to see exactly whats going on (and where its going wrong)
        on Monday morning i will put docs into maintenance mode and turn debugging up to the highest level and find out whats it doing from there

        Show
        Jordan Tomkinson added a comment - I have spoken to Eloy he is going to look at the code to see exactly whats going on (and where its going wrong) on Monday morning i will put docs into maintenance mode and turn debugging up to the highest level and find out whats it doing from there
        Hide
        Eloy Lafuente (stronk7) added a comment -

        Hi Jordan, were your last changes to Varnish satisfactory? From your message @ Jabber it seems that you finally got the option to pass those headers. Could you check if this query:

        SELECT rc_timestamp, rc_ip
        FROM recentchanges
        ORDER BY rc_timestamp DESC 
        LIMIT 1000
        

        has started to grab real IPs? That would be a great sign.

        Then, all we have to do is to block some user with recent editions (after now) and verify that the wiki does not get "blocked" anymore (surely checking that the corresponding "ipblocks" record is getting the real IP).

        Ciao

        Show
        Eloy Lafuente (stronk7) added a comment - Hi Jordan, were your last changes to Varnish satisfactory? From your message @ Jabber it seems that you finally got the option to pass those headers. Could you check if this query: SELECT rc_timestamp, rc_ip FROM recentchanges ORDER BY rc_timestamp DESC LIMIT 1000 has started to grab real IPs? That would be a great sign. Then, all we have to do is to block some user with recent editions (after now) and verify that the wiki does not get "blocked" anymore (surely checking that the corresponding "ipblocks" record is getting the real IP). Ciao
        Hide
        Jordan Tomkinson added a comment -

        Looks like its working Eloy, I'm seeing real IP's in the db now
        However the RecentChanges page is still not showing the IP's even though $wgPutIPinRC is true

        Show
        Jordan Tomkinson added a comment - Looks like its working Eloy, I'm seeing real IP's in the db now However the RecentChanges page is still not showing the IP's even though $wgPutIPinRC is true
        Hide
        Jordan Tomkinson added a comment -

        Adding eloy as watcher
        should we merge the 1.19 patch or another option?

        Show
        Jordan Tomkinson added a comment - Adding eloy as watcher should we merge the 1.19 patch or another option?
        Hide
        Helen Foster added a comment -

        Just tried in the 20/en wiki and found the problem fixed! Many thanks Jordan and Eloy

        Show
        Helen Foster added a comment - Just tried in the 20/en wiki and found the problem fixed! Many thanks Jordan and Eloy

          People

          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development