Cookie error message loading /catalog/admin/

[Captain Chaos]

I'm not one to just join and post questions without doing a little RTFM first, so please understand that I've been fighting with this problem for ~2 days now, and haven't found anything in the dox or the forums, so I decided to register and post.

My issue is that I've got a complete install of OsCMax 2.x, where the front end seems to work fine (no product of course - read on) but I can't seem to get into /catalog/admin/. In FF, the page takes a couple seconds to try to load, and I end up with

************************************************** *******

The page isn't redirecting properly

Firefox has detected that the server is redirecting the request for this address in a way that will never complete.


* This problem can sometimes be caused by disabling or refusing to accept cookies.


[Try Again]

************************************************** *******

and IE isn't smart enough to know what FF does, so it just keeps trying and trying, not doing anything.

I've checked my configure.php files again and again, making sure I've got my paths and domains right, as well as my connection params for the DB server. I've cleared cache, saved passwords, cookies, a 12-pack and a half a bottle of Jack (seems to help more often than not if you can believe that!). I've even gone so far as to completely reload the DB from the sql file included in the install as well as re-copying the files from the downloaded .tar.gz - nothing's working (except the alcohol).

What's really stupid about this is that I've got a working (test) install on another server, and I've even used the files from that install to replace the failed install - no go. What should I do (other than get more beer)? The one thing I can think of that I can't get to of course is the php.ini, so I'm wondering if I should create some test files to set and read cookies, just to see what succeeds/fails. If that's the recommendation, can someone tell me what specifically I should be doing with cookies to assimilate what OSCMax does?

Thanks a million in advance, and if I could I'd share my buzz with ya!

[Mushroom]

So if you turn off cookies in FF, do you get in?
If so, the first thing I would check is in configuration, Sessions. turn force cookie to false. Give that a shot....and since it Is NewYear's Eve, I think I might go do a shot myself.

[Captain Chaos]

First, thanks for the quick respose!

Second, I'm glad to see I'm not the only geek celebrating New Year's by hammering on the keyboard!

(more)

Okay, so I turned cookies off, and still get got the same response (kinda thought I would, but heck - anything's worth a shot).

Speaking of shots, good idea.

One thing I did notice when I turned cookies off was that I now get a URL where /catalog/admin/login.php sets the osCAdminID variable.

Your suggestion gave me another idea, but it still didn't help. I went into the DB and changed Force Cookie Use from False to True.

The only thing that ever changes is whether or not I get to see the osCAdminID var in the URL, and that seems solely dependent upon whether or not I have cookies enabled.

[michael_s]

This is most likely path problem, but it could also be the session directory. You may want to store sessions in mysql and see if that helps. Change it in your admin/configure.php file.

If you wouldn't mind, pm me your configure.php files (catalog and admin) minus the db info and I will take a look. Also send me the full server path so I can double check for you. No promises, but I wiill give it a shot.

You may also want to check if you have any mod_rewrite rules in .htaccess that may be causing a problem...

[Mushroom]

Do you get in if you go to ''/catalog/admin/configuration.php'' ?
I'm just wondering if it isn't a front end problem witht at big menu that comes up when you first sign on.
Since Michael has his hands on it, it will soon be solved.

[Captain Chaos]

Mushroom: I tried going to /catalog/admin/configuration.php, but it redirects me back to login.php, which is where I get hung up. I kinda had the same thought as you it seems - can I go directly to a specific page in the admin folder? Nope! would be the answer to that....

Michael had some great suggestions in his PM reply to me - he suggested being less restrictive in the cookie domain, by setting

PHP Code:

define('HTTP_COOKIE_DOMAIN', '.mydomain.com'); 


instead of

PHP Code:

define('HTTP_COOKIE_DOMAIN', 'mydomain.com'); 


He also suggested filling in the https domain for the admin panel,
even though I'm not using SSL:

PHP Code:

define('HTTPS_CATALOG_SERVER', 'http://mydomain.com'); 


He did suggest that I try using straight IP as opposed to hostname to eliminate any funky DNS issues, however this wouldn't work in this case because this box is hosting multiple virtual sites, and going straight IP made the box go "HUH?". Good thought, though.

Another suggestion he offered was to verify (or disable) the .htaccess file(s), which didn't help in my situation.

At this point, I'm:

a) still very open to suggestions;
b) *very* grateful for the already offered suggestions;
c) losing my buzz, and therefore my ambition;
d) feeling like I owe the community something "back" for the kind of help I'm getting on this.

I think it's time to reload the glass, and take a look at the working php.ini vs the non-working one.

Michael - would it be worth me making some quick cookie-test files, to see if that's where my problem lies? If so, can you tell me what to set and what to read, as far as cookies go so I can simulate what's going on?

Thanks again for everything!

[michael_s]

If the front end is working, your machine is already setting sessions/cookies correctly, so I do not think that it is a problem with cookies.

You can always access your site via IP. You simply have to switch to the IP plus username notation, even for machines with multiple name based virtual accounts. For instance on apache:

xxx.xxx.xxx.xxx/~username/admin/

On windows, you would use the IP plus the specific path:
xxx.xxx.xxx.xxx/path_to_osc/admin/

I forgot to ask, what OS and webserver are you trying to run this on?

One other thing to check - if you used FTP to upload the files, re-upload all the admin files. If one is corrupt or partially uploaded, all kinds of problems can occur.

[Mushroom]

Originally Posted by Captain Chaos

Mushroom: I tried going to

PHP Code:

define('HTTPS_CATALOG_SERVER', 'http://mydomain.com'); 


[color=#000000][color=#007700] [color=Black]He did suggest that I try using straight IP as opposed to hostname to eliminate any funky DNS issues, however this wouldn't work in this case because this box is hosting multiple virtual sites, and going straight IP made the box go "HUH?". Good thought, though.

Try the IP thing this way :

PHP Code:

define('HTTPS_CATALOG_SERVER', 'http://XXX.XXX.XXX.XXX/~accountname'); 


This does sound suspiciouly like the AOL proxy problem, where no matter what you do you get the same content. You wouldn't be going through a proxy, would you ? Clear all your caches !