Chrome Browser Mod_Rewrite Loop

Discussion in 'Setting-up protection' started by engineerwsu, Sep 18, 2015.

  1. engineerwsu

    engineerwsu Member

    Joined:
    Sep 18, 2014
    Messages:
    31
    I'm using Uniform Server for testing on a Windows 7 platform.

    I have been testing my protected content on various browsers. For testing I setup a simple folder with a simple file located at "test/test.html". The content of test.html is:

    <html>
    test protected content
    </html>

    I logged into the admin panel and added /test as a protected folder. As expected, an .htaccess file was created in the folder. Here is the content.

    ########### AMEMBER START #####################
    Options +FollowSymLinks
    RewriteEngine On

    # if cookie is set and file exists, stop rewriting and show page
    RewriteCond %{HTTP_COOKIE} amember_nr=([a-zA-Z0-9]+)
    RewriteCond C:/UniServerZ/www/data/new-rewrite/%1-2 -f
    RewriteRule ^(.*)$ - [S=3]

    # if cookie is set but folder file does not exists, user has no access to given folder
    RewriteCond %{HTTP_COOKIE} amember_nr=([a-zA-Z0-9]+)
    RewriteCond C:/UniServerZ/www/data/new-rewrite/%1-2 !-f
    RewriteRule ^(.*)$ http://localhost/no-access/folder/i...{QUERY_STRING}&host=%{HTTP_HOST}&ssl=%{HTTPS} [L,R]

    ## if user is not authorized, redirect to login page
    # BrowserMatch "MSIE" force-no-vary
    RewriteCond %{QUERY_STRING} (.+)
    RewriteRule ^(.*)$ http://localhost/protect/new-rewrite?f=2&url=%{REQUEST_URI}?%1&host=%{HTTP_HOST}&ssl=%{HTTPS} [L,R,B]
    RewriteRule ^(.*)$ http://localhost/protect/new-rewrite?f=2&url=%{REQUEST_URI}&host=%{HTTP_HOST}&ssl=%{HTTPS} [L,R]
    ########### AMEMBER FINISH ####################

    I have successfully tested with Firefox 40 and IE 11. However, testing with Chrome 45 results in an error "this webpage has a redirect loop." The android browser appears to give me the same error message.

    I have cleared the chrome browser cache a few times and restarted it. When I delete the .htaccess file, I have to problem accessing the content. The problem is obviously the .htaccess file or maybe the setup of amember, but I'm not sure which.
  2. alexander

    alexander Administrator Staff Member

    Joined:
    Jan 8, 2003
    Messages:
    6,279
    What version of aMember do you have installed? Upgrade your installation to latest version and test again. As I remember there was such issue and it was fixed.
  3. engineerwsu

    engineerwsu Member

    Joined:
    Sep 18, 2014
    Messages:
    31
    I am using version 4.6.3. I noticed that if I set the site root to "localhost," the .htaccess file in the protected folder does not get updated accordingly. I have to remove all protected folders and recreate them so that the .htaccess file makes the appropriate entries.

    If I change the site root to "localhost" and update the .htaccess file, I do not get the redirect error message. However, if I use my local IP address instead (and update the .htaccess file in the protected directory), I see the message once again. The message does not appear for IE and firefox.

    I have cleared all cookies again and flushed dns. Problem persists.

    Again I tried simply deleting the .htaccess file in the protected folder. The error message goes away. I'm not very knowledgeable on mod_rewrite, but it seems there is some variable or function being used that chrome does not like when the site root is not equal to "localhost."
  4. engineerwsu

    engineerwsu Member

    Joined:
    Sep 18, 2014
    Messages:
    31
    After a process of elimination, I don't think the user is getting authenticated correctly. Maybe this has something to do with the saved cookie. The first check in the .htaccess file is to see if the HTTP_COOKIE exists. If so, display the content. However, I systematically commented out certain lines to determine that this first check is not passing. As a result, the .htaccess file moves to the final "if user is not authorized..." statement.

    It's possible that the redirect loop is that the user is being kicked back to the login to authenticate, but the user is already logged in, so the script bounces back and forth. Just a guess.

    I verified that the cookie saved for the chrome browser:

    Name:pHPSESSID
    Content:u5j34csssnkl6431uig0hrgk85
    Domain:192.168.100.100
    Path:/
    Send for:Any kind of connection
    Accessible to script:No (HttpOnly)
    Created:Monday, September 21, 2015 at 12:08:27 PM
    Expires:When the browsing session ends

    Any help would be greatly appreciated. This problem stops all function on an android browser or chrome browser.
  5. engineerwsu

    engineerwsu Member

    Joined:
    Sep 18, 2014
    Messages:
    31
    Okay I spent some time troubleshooting this problem and have a solution that seems to work for me. The issue appears to be that when using an IP address rather than a domain name, chrome browser refuses to save the cookie. The PHPSESSID is set, but the amember_nr cookie is not. This creates some kind of authentication loop within the mod_rewrite module. As mentioned above this problem also exists with Android native browser.

    After discovering that the design of chrome disallows cookies with a domain name equal to an ip address, I decided to NULL the domain name. So far this has worked. Just to clarify, I would not encourage using this configuration for a production site simply because it's not needed. When aMember is loaded on web server accessed using a FQDN, this issue will not be present which is probably why there has been so little discussion on this topic yet. I do a lot of local development on various systems and mobile devices so I need access to my sites remotely. Using an IP address hasn't been a problem until now. I think I will introduce a custom routing in my router and use mydomain.dev or some other domain name and route that to the web server.

    There is a file called new-rewrite.php located at: /application/default/plugins/protect that creates the cookie called "amember_nr" which is the culprit.

    I changed the original code:
    Am_Controller::setCookie(self::NR_COOKIE, $cookie, time()+$this->getDi()->config->get('login_session_lifetime', 120)*60, '/',
    $this->getDi()->request->getHttpHost());

    to this code:
    Am_Controller::setCookie(self::NR_COOKIE, $cookie, time()+$this->getDi()->config->get('login_session_lifetime', 120)*60, '/',
    NULL);

    So far, I've not noticed any ill affects on my site, but I'll be reverting the code for any production work.
  6. alexander

    alexander Administrator Staff Member

    Joined:
    Jan 8, 2003
    Messages:
    6,279
    Hi,
    Well this issue was fixed in 4.7 already. And it was fixed a little different way. The problem was in Am_Controller::_getCookieDomain($d) function. That function didn't return valid cookie domain if you use IP address instead of domain. For example for IP 8.8.8.8, cookie domain was set to .8.8.8.8 and that doesn't work in Chrome.
    So, upgrade your installation to latest version.
  7. engineerwsu

    engineerwsu Member

    Joined:
    Sep 18, 2014
    Messages:
    31
    Super! I will check the change logs and perform the upgrade. Cheers!

Share This Page