The MU forums have moved to WordPress.org

WPMU on Intranet - Can't log in? (9 posts)

  1. ancawonka
    Member
    Posted 14 years ago #

    Hello!

    I am installing WordPress MU on a server in our intranet. The server and site show up with the url http://wordpress-dev/wordpress-mu. However, I am unable to log in, because cookies are not being set for this domain.

    I have no problem logging in from Safari, and I can see cookies being set for "wordpress-dev" and ".wordpress-dev' (in Safari). Is this a Firefox issue?

    Here are some relevant statements from my wp-config.php file:

    $base = '/wordpress-mu/';
    define('DOMAIN_CURRENT_SITE', 'wordpress-dev' );
    define('PATH_CURRENT_SITE', '/wordpress-mu/' );

    ---

    I found a possible explanation: http://stackoverflow.com/questions/1019876/cookie-on-an-intranet-domain

    ---

    What are some possible solutions? I tried changing the DOMAIN_CURRENT_SITE definition, and that was totally not the right thing to try. Is there a way to work around this other than changing the domain name on the server side?

  2. ancawonka
    Member
    Posted 14 years ago #

    Here are a few more things related to this issue... I got a little closer but not 100% resolved...

    What I've tried is:

    0. Update the VirtualHosts directtive with a "serverAlias = wordpress-dev.mydomain.com" directive.
    1. Go into the wpmu database and change the "domain" field in the wp_blogs and wp_site tables to "wordpress-dev.mydomain.com".
    2. Update wp-config.php:
    define('DOMAIN_CURRENT_SITE', 'wordpress-dev.mydomain.org' );

    Firefox is now accepting the test cookie, but I can't log in from either browser anymore. The Admin link is still pointed to the old URL (http://wordpress-dev/) instead of the new, fully-qualified domain.

    Is there a different setting for the admin domain? Time to search.

  3. kgraeme
    Member
    Posted 14 years ago #

    There's likely some places in the db you've missed. Following this domain name change approach, try exporting the db to a .sql file, run a find/replace of the name to make it the FQDN, then reimport it.

    (Filling in for Andrea in her jetlagged state.)

  4. andrea_r
    Moderator
    Posted 14 years ago #

    Yep, and a darn fine job too.

    (oh man, traveling sucks.)

  5. ancawonka
    Member
    Posted 14 years ago #

    Thanks for the help, @kgraeme and @andrea_r. I did an sqldump and text search/replace, which seems to have solved my problem. I am now able to log in from FF and Safari, and cookies are set correctly.

    There appear to be a lot of options that store the full URL of the site, but they are not available to edit in the user interface. So it's great to remember that I have the power of database search and replace. Mwahahah!

  6. ssandison
    Member
    Posted 14 years ago #

    What if you want to be able to use a domain like intranet? Is there any way to get MU to work for that domain. I'm thinking of circumstances like a corporate intranet. I know that the company I work for would not be prepared to use a different domain and its a shame that it seems WordPress can't be used in that circumstance.

  7. ssandison
    Member
    Posted 14 years ago #

    I've tried setting COOKIE_DOMAIN to false and that seems to work. Not sure what ramifications there are if any yet.

  8. hfossli
    Member
    Posted 14 years ago #

    yup. define('COOKIE_DOMAIN', FALSE) works.

  9. miguelcudaihl
    Member
    Posted 14 years ago #

    Thanks. Adding define('COOKIE_DOMAIN', FALSE) in the configuration did the job. Had troubles initially and turned out I should've placed the line on top of require_once(ABSPATH . 'wp-settings.php');

    A suggestion though. How about set COOKIE_DOMAIN to false by default if the administrator selected sub-directories during installation?

    My linux box is named linuxmint8. I do not understand why calls to setcookie with user-provided domain (i.e. linuxmint8 or .linuxmint8) are not stored by Firefox nor IE. However, if the domain isn't provided FF and IE have no troubles with storing the cookie. In both cases, using HttpFox, the cookie domain is set to linuxmint8.

About this Topic

  • Started 14 years ago by ancawonka
  • Latest reply from miguelcudaihl