The summer holidays in the Northern hemisphere have begun, and some of our regular contributors will be on the road from the 1st to the 20th of July, 2018.

During this time we will do our best to stay on top of questions that are posted...but if you can contribute by answering the questions of others, that would be great. Thanks : )

Gibbons on the loose!

I am being told that the Gibbons have escaped whenever I click a Submit button when changing an Admin setting (e.g. School Admin>Manage School Year).

The only odd configuration that I can think of is that Gibbon is running behind an Apache reverse proxy, perhaps Gibbons do not like being aped!

What direction should I take to re-tame the Gibbons?


Comments

  • I should mention that the setting does seem to be taking despite the flight of the Gibbons.

    Thank you,

    FV
  • Upon further investigation it appears to have nothing to do with the reverse proxy. The problem persists when the proxy is bypassed.

    I have my suspicions about the URL being malformed somehow. Here is an example:

    https://gibbon.spots.school/c//index.php?q=/modules/School%20Admin/schoolYear_manage_edit.php&gibbonSchoolYearID=022&return=success0

    It seems the URL section "School Admin" is being double escaped so twice the number of Gibbons are getting out!

    Maybe we can turn these Gibbons back into great apes?

    The browser (Safari) window title seems to corroborate the story:


  • Installation details: Gibbon v15
    Linux system (Cloud VM): Fedora 27 4.13.9-300.fc27.x86_64
    PHP version: 7.1.16
    Server version: Apache/2.4.33 (Fedora)
  • edited April 13
    Hi fvlasie,

    This is unusual, you're right it does appear to be caused by the URL double-encoding. I wonder if it's something in the server configuration that's modifying the header Location: string, as I don't believe we've seen this particular issue before.

    To help debug:
    • Try a different browser (if you haven't already), to narrow down if it's front-end or back-end.
    • Test to see if this happens just in School Admin, or in any module with a space in the name (try System Admin for example)
    • Do you have any redirection or mod-rewrite lines in your directory-level .htaccess or server-level httpd.conf that may be encoding the URL as part of the redirect? Sometimes related to subdomain or https setup.

    Hope we can help tame your Gibbon escapees :smiley: Give a shout if you find any more clues as you troubleshoot this. Thanks!
  • Hello Sandra,

    I just tried a different browser (Firefox) and the problem persists.

    It also occurs with other space-in-the-name modules.

    So we are narrowing it down...these are some pretty crafty Gibbons!

    BTW, thank you for the Data Admin module, it is wonderful! It saved me hours and hours of work.
  • Thanks!! When my school started up with Gibbon we had 10 years of data in a previous system, creating a way to migrate it all over was a top priority. Glad to hear it's been useful for you too.

    Is there any redirection setup on your server either in the directory-level .htaccess or server-level httpd.conf? Perhaps related to the proxy? If it's mod-rewrite related, adding [NE] or [NE,B] to the redirection may stop if from double-escaping: https://stackoverflow.com/a/6529394
  • This is the only URL modifying code I am using in my Apache config:

    # redirect http to https
    #nohttps
    RewriteEngine On
    RewriteCond %{HTTPS} !=on
    RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,L]


    The Gibbon install folder is unmodified except for user permissions and selinux contexts.

    Maybe there is something up with the php version I am using?
  • The previous post changed my config code:

    # redirect http to https <VirtualHost *:80> #nohttps RewriteEngine On RewriteCond %{HTTPS} !=on RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [R,NE,L] </VirtualHost>

    I have now added the NE but the problem remains. I would be surprised if Gibbon were providing http rather than https to the browser after form submission.

    I do have my base URL set with https BTW.

    I'm stumped...
  • It seems the code feature of Vanilla forums does not support line breaks. :(
  • The redirect URL is based on your Base URL in System Settings, so if that url starts with https:// then all the links and redirects Gibbon uses will also be https (and shouldn't trigger the RewriteRule).

    If this is in your Apache config though you'd also need to restart after making any changes (such as adding the NE).
  • Yes, I did restart, both Apache and php-fpm...

    I just realised that your amazing Data Admin module is NOT exhibiting the problem despite having a space in the name. The Gibbons have not gone totally feral...

  • This a real headscratcher...


    sandra
  • edited April 13
    Hmm. In your initial URL I see what looks like a double slash in the Base URL: https://gibbon.spots.school/c//index.php Is there a trailing slash on the end of your Base URL in System Settings? If so, remove it, then log out and back in again (to refresh the Session) and see if that does the trick. The extra slash may be triggering an internal redirect which could double-encode the GET params.
  • Yes, actually I already caught that! (I have been poring over these settings...)

    Unfortunately it made no difference.
  • Would you like access to gibbon.spots.school?
  • I suspect it's server configuration or redirect related at this point. For example, if I visit https://gibbon.spots.school it will redirect to https://gibbon.spots.school/c/, is this a redirect in the .htaccess or httpd.conf file (and perhaps needs [NE] added to it too?)

    As a test, if I visit http://gibbon.spots.school/c/index.php?%40 it is redirecting to https://gibbon.spots.school/c/index.php?%2540 which is double-encoded, and seems to indicate the previous change adding [NE] hasn't affected anything ... but this is a tricky one to nail down, there's no saying if the https redirect is even related to the current issue (from some google searches, it does seem to be a common cause though).
  • sandra said:

    I suspect it's server configuration or redirect related at this point. For example, if I visit https://gibbon.spots.school it will redirect to https://gibbon.spots.school/c/, is this a redirect in the .htaccess or httpd.conf file (and perhaps needs [NE] added to it too?)

    This one is a REFRESH header in index.html <html><head><meta HTTP-EQUIV="REFRESH" content="0; url=/c/"></head></html>

    As a test, if I visit http://gibbon.spots.school/c/index.php?%40 it is redirecting to https://gibbon.spots.school/c/index.php?%2540 which is double-encoded, and seems to indicate the previous change adding [NE] hasn't affected anything ... but this is a tricky one to nail down, there's no saying if the https redirect is even related to the current issue (from some google searches, it does seem to be a common cause though).

    Aha, so it does seem to be Apache's fault. I will focus my search on that...thank you!
  • sandra said:

    I suspect it's server configuration or redirect related at this point. For example, if I visit https://gibbon.spots.school it will redirect to https://gibbon.spots.school/c/, is this a redirect in the .htaccess or httpd.conf file (and perhaps needs [NE] added to it too?)

    This one is a REFRESH header in index.html <html><head><meta HTTP-EQUIV="REFRESH" content="0; url=/c/"></head></html>

    ^I wrote this^

  • edited April 13
    Another avenue to look into is the default encoding for your server, here's an example of how to ensure it's set to UTF-8: https://stackoverflow.com/a/10926894

    On a regular Gibbon page, the <meta charset="utf-8"> in the head sets the encoding for that page. However, on a redirect page the is never output, it's superseded by the Location: redirect, so in this case perhaps the server is falling back to a default encoding that's not UTF-8? Maybe? Worth a shot.

    Good luck!
  • AddDefaultCharset UTF-8

    is already active in httpd.conf :/
  • Okay, worth a try. Sometimes it's there by default but commented out with a #.
  • Well, I cannot find any clues for now.

    I was just wondering if there is any difference in the way Data Admin submits forms and the way the other modules do it. Data Admin does not seem affected, maybe the other modules are triggering some Apache bug.

    Maybe I will test a second install on a new machine tomorrow.

    谢谢你
  • Yep, the Data Admin importer form posts back to itself rather than redirecting (which is not good practice, my php was a bit rusty when I first wrote that part :sweat_smile:). So it certainly seems related to the header redirect.

    I'm out of ideas (for the moment), perhaps someone else on the forums has dealt with something similar. Testing with a different machine couldn't hurt too. Best of luck!
  • YEY! :)

    I found the Gibbons!

    Do you remember I mentioned the reverse proxy? Well, the reverse proxy is also redirecting http to https. The proxy needed the NE added to the rewrite rule too.

    It is a complicated setup, but I need both rewrites in place because people need to access Gibbon both on and off site.

    If you try your index.php?%40 trick you will see that it now works, it stays as %40.

    Thank you, Sandra, for working with me on this!

    (BTW, I like the way Data Admin handles form submission. :) )
  • One thing that still puzzles me is that the rewrite rule should only be applying to the initial http request. Once switched, everything should be httpS and the rewrite rule should not apply. Is it possible some of the Gibbon code is accidentally using http (not https)?
  • Glad to hear you got it working!

    Gibbon uses the Base URL for all url-relative links and redirects, so as long as the base path starts with https:// it shouldn't be capable of falling back to plain http://. Perhaps something system-config related? Or another mystery altogether...
  • edited April 17
    I think this one takes the Gibbon forum prize for the longest, fastest most in-depth thread where a complex problem was solved. Not to mention the great images! Well done : )
    sandra
Sign In or Register to comment.