Geeklog Forums

Hi Guys,

I was hoping that somebody might have some advice for me as to why I'm getting the "Can't login" problem as illustrated inthe FAQ. It seems that there are definitely documented solutions to this problem in the FAQ and in the forums, but after trying everything I've read along with everything I can think of to fix it, I am still dead in the water.

The site is http://www.ccsf.edu/~asweb, it was just migrated from http://hills.ccsf.edu/~asweb where it went through some preliminatry testing and passed. Both sites are rather strict with security so they run under php-cgiwrap with register-globals equals off. I extract all environment variables early in lib-common.php and this works fine on the testing site, but when we migrated over to the target site, we cannot get Geeklog to send a cookie. I've written a short test script to make sure that cookies can be set from that server, since it is a virtual host with a redirected username and my script set a cookiie no problem. I checked for whitespace (10 times), and i've toggled values for cookiedomain a few dozen times in every different combination I can think of.

Please help, anyone?

This is a City College of San Francisco, school project. It is for a non-profit associated with the school, so if anybody has any ideas, don't worry, you won't be doing my job for me, you'll just be helping me out of this rut.

thanks in advance,

Andrew

Did you FTP the individual files to the stite and if so, did you upload in ASCII?

If you made this error then you MUST start again

cheers

Did you FTP the individual files to the stite and if so, did you upload in ASCII?

If you uploaded in Binary you MUST start again, uloading in ASCII

cheers

it seams to be working it let me register

Hi,

Thanks for the help, guys. Yes, I believe the other system administrator did, in fact, upload stuff over ftp, and I don't know if it was in ASCII format or not. I'll have to retry uploading stuff. I did do this for the lib-common.php, config.php, index.php and the like, but...

Registration does seem to still work, but cookies are still not being set. (I guess registration doesn't depend on the cookies.) But can you log in after registering?

Thanks again for your help. Any more thoughts would be greatly appreciated.

-Andrew

I had a similar problem just yesterday when I made some changes to some "add-on" domains that point to Geeklog.

Here is a FAQ that cured my problem: FAQ about login

Once I changed the cookie settings in my config file, everything worked.

Have you tried different browsers to see if some work and some don't?

I never had a problem with Mozilla or Firefox. IE wouldn't let me log in until I changed my cookie settings.

Blessings!

inSPIREmin

---

www.Scripturetoolkit.com www.inSPIREministries.com

Thanks. It seems that possible problems from that FAQ entry that may exist on the site are in items 3, 4, or 5. I've asked the admin about filtering cookies (item 2). He says he doesn't. Item 1 shouldn't be a problem as I can get cookies from all my other geeklog sites in the browser I'm using. I've tried Konqueror, in adition to my default browser of Mozilla. Item 6 is not an issue for the site -- I've cleared out cookies numerous times within the browser. This leaves Items 3, 4 and 5.

Item 3 says: "You are using frame forwarding or some other means of "hiding" the real URL of your site. Browsers, however, will only accept cookies from the real domain. You should set the $_CONF['cookiedomain'] variable to point to the real domain, not to the domain that's displayed in the browser's URL field in such a case." I asked the admin about this and says he doesn't do "frame forwarding", but there is some virtual host redirection going on. Setting cookiedomain should deal with that though. My other concern with that "Browsers, however, will only accept cookies form the real domain." What does "real domain" mean in this context? What the box is listed as in /etc/hosts? What the webserver thinks it's ServerName is? Or what the FQD name is of the computer itself?

Item 4 is still in question as I don't know what the "real domain" to put in the cookiedomain config variable is.

Item 5 is in question since it may just be that the original files were uploaded in binary format. I'm working on this one next, but I'm suspecting that this isn't the issue because the files that deal with the setting sessions and cookies and such have all been re-uploaded already.

Unfortunately, the admin will only allow me ftp access, so I'm using re-uploaded the entire archive as a last resort since it is so prone to failure and transfer issues.

Thanks for all your help!

-Andrew

Your site is definitely being redirected. Try either "http://www.ccsf.edu/~asweb" or
"http://cloud.ccsf.cc.ca.us/~asweb/" and see if that solves your problem.

By the way I signed up to the site and did not get a password sent to me, although I did get an email confirming that I signed up. I wanted to try to log on and see the problem for myself.

Good luck.

Yeah, I've been messing around with www.ccsf.edu and cloud.ccsf.cc.ca.us for the cookiedomain variable to no avail. Thanks for the input. I'm thoroughly confused at this point though, does cookiedomain need to be the real name of the server (FQDN), or what the WebServer thinks it is? And does cookiedomain need to match site_url?

Thanks again,

Adnrew

Try setting

$_CONF['site_url'] = 'http://cloud.ccsf.cc.ca.us/~asweb';

and

$_CONF['cookiedomain'] = '';

bye, Dirk

K. I've tried that, but I'll try that again right now.

Also, I just found a few files in the geeklog/system/pear diretory with no closing php tag. I'm not sure if they were my fault or if they are in the main distro like that, but you might want to check. From the shell I did:

for i in `find /path/to/geeklog -type f | grep ".php$"; do echo $i; tail -1 $i; done | less

Then, visually inspect that there is no extra whitespace, and that all php files are closed with a php tag. Like I said this turned up a couple missing closing tags in the main distribution in files that I never touched. Might want to try running that on the main archive.

Thanks,

Andrew

I just got a message from the admin. I was asking him to send me the config file for Apache so I can see how the redirects work and what the server thinks its name is. He wrote back saying that the only relevent lines he thought were the following:

ServerName www.ccsf.edu


UserDir .



So, this means that the Apache server thiniks it's name is www.ccsf.edu. So, should I have site_url set to this?

And is it a problem to have UserDir be the working directory for that user? I've only set up under public_html before, where the user has a normal directory and geeklog dir is outside of public_html. The way he insists on setting up (apparently because this is how it has been done and other sites now depend on it) is to make the entirety of the user dir as public_space, like the above stanza dictates, however, could my problem be stemming from the fact that geeklog dir is not outside the web space?

Thanks,

Andrew

oh, and cookiedomain set to blank single quotes like dirk suggested didn't seem to get a cookie to set.

Last time I tried, http://www.ccsf.edu/~asweb/ was redirected to http://cloud.ccsf.cc.ca.us/~asweb/ - so that's why I suggested using the latter URL.

It seems the server configuration has changed since then, as it now stays at http://www.ccsf.edu/~asweb - so try that for the $_CONF['site_url'].

If you leave $_CONF['cookiedomain'] empty, Geeklog will try to guess the correct value, using the $_CONF['site_url']. In your case, '.ccsf.edu' would be the correct value (now). So if the empty string doesn't work, try that.

bye, Dirk

yup, I flipped it back to www.ccsf.edu for site_url to see if that would make a difference. I believe now that there is indeed another layer of abstraction happening somewhere (like initial requests are being sent to another server that redirects to the right place.) Any ideas about that user_dir configuration option?

Thank you!

Also, did you notice that the static pages are mixed up too? I'm not sure if these issues are related. Man, I've been banging my head against this one for the better part of the last month and I am positively resolved to figure it out today! grrrr.

so I've tried every possible combination of cookie_domain and site_url. Many of which should have been valid. I think the problem lies somewhere else, but I can't see it. Does anybody have any other ideas?

Thanks again for the help. You guys are great.