We launched new forums in March 2019—join us there. In a hurry for help with your website? Get Help Now!
    • 22827
    • 129 Posts
    Edit: This problem happens to all browsers, but the login fails only on IE possibily due to the cookie

    I have some private pages, and I have a resource with a login form that is marked as the "unauthorised page" (lets say this is called login.html)

    The domain I am using is "domain.com" - ie, with no "www" prefix.

    When I go to an unauthorised page (say http://domain.com/private.html) the URL remains the same, but the content from the page login.html is presented. This is all correct, and matches firefox and chrome.

    The problem is that once this page is displayed, all of the URLs generated for the page are suddenly prefixed with www.

    So the login "submit" button now goes to http://www.domain.com/login.html

    This messes up the cookie by the look of it, and login fails. The base_href changes in the headers, whereas before I navigate to an unauthorised page, the base_href is correct.

    So it looks like ++site_url is changing when I get to an unauthorised page. Is this likely?

    This is revo 2.2.8pl



    [ed. note: paulkoan last edited this post 11 years, 10 months ago.]
      • 28042 ☆ A M B ☆
      • 24,524 Posts
      First, please please upgrade your site, at least to the latest 2.2 branch if not to the 2.3 branch.

      Are you sure that the login form's action attribute URL is not hard-coded? Is the login form using a template with the wrong base meta tag in its head?

      The ++site_url is generated automatically upon each page request in the config.inc.php file. Unless it's hard-coded somewhere, it's always going to be the URL the page was requested as.
        Studying MODX in the desert - http://sottwell.com
        Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
        Join the Slack Community - http://modx.org
        • 22827
        • 129 Posts
        Thanks Susan,

        Yes, this site is being upgraded as part of this process.

        I figured it out. At some point, the private part of the site was visited with the www. prefix and there wasn't a redirect in place. This caused the page used as the unauthorised page to be cached with the www. prefix in the URLs for the menus and forms.

        Once I cleared the MODx cache, and put the redirect in place, it stopped happening.
          • 28042 ☆ A M B ☆
          • 24,524 Posts
          Heh. I had another domain pointed at my site for a while, and I kept getting that domain in my links, until I wised up and added a line to my rewrite rules to rewrite those to my domain.

          You might do better with a rewrite in your web server's rewrite rules than a redirect. The ht.access file comes with a sample to rewrite www.domain.com to domain.com, and vice verse, that works for Apache. nginx is different, of course, but not any more difficult.
            Studying MODX in the desert - http://sottwell.com
            Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
            Join the Slack Community - http://modx.org
            • 22827
            • 129 Posts
            Quote from: sottwell at Nov 13, 2014, 09:30 AM

            You might do better with a rewrite in your web server's rewrite rules than a redirect.

            The redirect was done with rewrite rules - I think that is what you mean. It is important that it results in a redirect to avoid cookie issues and dupe content in search indexes.