By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
460,022 Members | 1,212 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 460,022 IT Pros & Developers. It's quick & easy.

Problems migrating from IIS to Apache

P: n/a
Hi,

I'm trying to move our web site from a Windows 2000 box running IIS /
PHP CGI (4.0.6) to a RedHat box running Apache (actually IBM HTTP
Server v2.0.47) & PHP 4.3.10.

First of all, I didn't develop our web site - a consulting firm did it
about three years ago & it's pretty complex. I feel comfortable with
PHP, but parts of this code I just can't figure out. They relied
heavily upon register globals, it seems - so I've had to re-enable that
in php.ini on the Linux box. There's just too much code for me to go
back & re-write it all - I really just want to move the site over to
this new box. I'm kind of between a rock & a hard place in that I
really can't do anything to the web server - we're running IBM
WebSphere App server & Portal on the box and IBM wants this version of
the HTTP server... I've tried getting an older version of PHP to
compile against the HTTP server & it just doesn't work...

When I moved the code from the Windows box to the RedHat box, the first
thing I got when loading "http://mydomain" was a redirect to
"http:///?".

Looking through the code, I see that they set a cookie & do some checks
against the user database (mysql)... I think this is where the problem
lies, but I'm not sure how to go about fixing it...

There's a lot of code so I'm only posting the parts I think are
relevant... if we need to look at more I can post it...

INDEX.PHP:

<?PHP
include("./includes/common.inc.php");
pageStart();
?>

html stuff is here

<?
pageEnd();
?>
INCLUDES/COMMON.INC.PHP:

<?PHP

$COPYRIGHT_START = 2001;

## MySQL connectivity variables
$DB_NAME = "database";
$DB_HOST = "localhost";
$DB_PORT = "3306";
$DB_USER = "user";
$DB_PASS = "pass";
}

$BASEURL = "";
$DOCUMENT_ROOT = "/opt/IBMIHS/htdocs/en_US/mysite";
$ROOTPATH = "$DOCUMENT_ROOT";

## Debugging (un-comment to use)

NOTE: I FOUND THAT IF I UNCOMMENT THIS STUFF, THE PAGE ACTUALLY
RENDERS - I JUST GET A PHP ERROR ABOUT THE HEADERS HAVING ALREADY BEEN
SENT

/*
echo "<p>BASEURL = " .$BASEURL. "<br>\n";
echo "PATH_INFO = " .$PATH_INFO. "<br>\n";
echo "PATH_TRANSLATED = " .$PATH_TRANSLATED. "<br>\n";
echo "DOCUMENT_ROOT = " .$DOCUMENT_ROOT. "<br>\n";
echo "ROOTPATH = " .$ROOTPATH. "</p>\n";
echo ($SERVER_NAME.$SCRIPT_NAME ." ||| ". $BASEURL."/index.php");
*/

## == Admin User Stuff ============

$AdminUser = Array(); // Array containing admin user data
$AdminUser["ID"] = 0;
$AdminUser["Name"] = "";
$Access_Denied = 0;

$cookie_username = $HTTP_COOKIE_VARS["site_adminname"];
$cookie_usersess = $HTTP_COOKIE_VARS["site_adminsess"];

IF ($cookie_username!="" && $cookie_usersess!="" &&
$cookie_usersess!="x") {
## Note: any text sent to the browser before you call
setcookie() will kill it.
## This is because setcookie() must be run and send its info to
the browser in with
## the headers.

$dbh = dbconnect();
$query = "SELECT * FROM Admin_Users WHERE
UserName='".$cookie_username."' ";
//echo $query;
$query = mysql_query($query);

if (mysql_num_rows($query)){
$row = mysql_fetch_object($query);
if ($cookie_usersess ==
md5($cookie_username.($row->UserPass))) {
## cookie session is correct
$AdminUser["ID"] = $row->UserID;
$AdminUser["Name"] = $row->UserName;

setcookie("site_adminname", $cookie_username,
time()+432000, "/");
setcookie("site_adminsess", $cookie_usersess,
time()+1200, "/");
}

} else {
## invalid session
setcookie("site_adminsess", "x", time()+1200, "/");
$cookie_usersess = "";
}

dbclose($dbh);
}

## SECURE-SOCKETS-LAYER ################
if (($AdminUser["ID"] > 0) || ($forceSSL==true)) {
## force ssl
if ($HTTPS != "on") {
header("location:
https://$HTTP_HOST$PHP_SELF?$QUERY_STRING");
}
} else {
## non-admin; don't use https
if ($HTTPS != "off") {
header("location:
http://$HTTP_HOST$PHP_SELF?$QUERY_STRING");
}
}


There is more code after that, but only various functions called by the
pages in the site... I really think the problem has to do with
"setcookie" - based on the comments in the code... I just don't know
how to fix it!

If anyone has a suggestion I'd be happy to hear it.

Thanks,
Kelly

Jul 17 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a
Just in case ... :)

Your posting of the contents of common.inc.php includes a stray closing
brace "}" after $DBPASS is set. Is this not a stray, but rather the end
of a previous class/function?

Jul 17 '05 #2

P: n/a

StupidScript wrote:
Just in case ... :)

Your posting of the contents of common.inc.php includes a stray closing brace "}" after $DBPASS is set. Is this not a stray, but rather the end of a previous class/function?


Thanks, but sorry... that was a typo on my part. The "}" is *not* in
the live script... wasn't paying attention to what I posted.

Jul 17 '05 #3

P: n/a
To follow up to my own message, I found a few things...

First of all, I noticed that the tables in the MySQL database on the
windows server all had lowercase names. However, in the PHP scripts,
the author had referenced them with different capitalization (eg users
-vs- Users)... I think this matters on Linux :-) Anyways, I've gone
back and rebuilt the MySQL database on the Linux box with the correct
capitalization.

Another thing, I had made changes to php.ini but I realized that I had
forgotten to restart apache... After doing so, I see something
different... when opening http://myhost the browser just sits there &
spins... in the access log on the server, I see:

192.168.2.12 - - [04/Mar/2005:18:18:04 -0500] "GET /foo/index.php?
HTTP/1.1" 302 1125
192.168.2.12 - - [04/Mar/2005:18:18:04 -0500] "GET /foo/index.php?
HTTP/1.1" 302 1125
192.168.2.12 - - [04/Mar/2005:18:18:04 -0500] "GET /foo/index.php?
HTTP/1.1" 302 1125
192.168.2.12 - - [04/Mar/2005:18:18:04 -0500] "GET /foo/index.php?
HTTP/1.1" 302 1125
192.168.2.12 - - [04/Mar/2005:18:18:04 -0500] "GET /foo/index.php?
HTTP/1.1" 302 1125
192.168.2.12 - - [04/Mar/2005:18:18:04 -0500] "GET /foo/index.php?
HTTP/1.1" 302 1125

....over & over again... like it's in a loop somewhere - the browser
gets index.php, then index.php redirects it back to itself over &
over... In Mozilla on the server, I actually get an error that the max
# of redirects has been reached.

Anyways, still working on it, just a few more bits of info.

Thanks!
Kelly

Jul 17 '05 #4

P: n/a

we*******@gmail.com wrote:
Hi,

I'm trying to move our web site from a Windows 2000 box running IIS /
PHP CGI (4.0.6) to a RedHat box running Apache (actually IBM HTTP
Server v2.0.47) & PHP 4.3.10.

....snip...

I figured out the problem... but maybe someone can explain why it was a
problem in the first place?

I had to change

header("location: http://$HTTP_HOST$PHP_SELF?$QUERY_STRING");

-to-

header('P3P: CP="IDC DSP COR CURa ADMa OUR IND PHY ONL COM STA"
location: http://$HTTP_HOST$PHP_SELF?$QUERY_STRING');

now it works... apparently IE6 (which unfortunately was the only
browser I had tried using) was rejecting the cookie because of the
privacy policy. The screwed up thing was that I had suspected that
earlier & added my new server to the sites IE should always allow
cookies from... but the page didn't start working until I added the
extra privacy stuff to the header...

How f#cking stupid! 9 hours wasted because of IE...

Cheers.
Kelly

Jul 17 '05 #5

P: n/a
we*******@gmail.com wrote in news:1110020177.767059.299660
@o13g2000cwo.googlegroups.com:

...snip...

I figured out the problem... but maybe someone can explain why it was a
problem in the first place?

I had to change

header("location: http://$HTTP_HOST$PHP_SELF?$QUERY_STRING");

-to-

header('P3P: CP="IDC DSP COR CURa ADMa OUR IND PHY ONL COM STA"
location: http://$HTTP_HOST$PHP_SELF?$QUERY_STRING');

now it works... apparently IE6


^^^

There's why it was a problem in the first place.

I've had to modify the login code on any number of sites since IE6 came
out, for this exact reason. We used cookies for authentication on a lot of
sites for a long time without issue, then came IE6, and things "broke," and
users started complaining that they couldn't login. I don't understand the
supposed logic any more than you do. "Let's require a new header before we
accept cookies. Meanwhile, anyone can send this header at will, regardless
of their actual privacy policy." Yeah, that's really reassuring.

Worse, in many cases IE6 _still_ won't accept a cookie even after receiving
the P3P header, if the user's "Privacy" setting is above "Medium High."
Naturally, the end user who stumbles upon this setting sets it to the
highest level, not paying attention to the tooltip about how it's going to
block everything, because they're pumped full of fear about spyware and
whatnot. It's driven me back to preferring .htpasswd based authentication,
and while I still use cookies heavily, I no longer assume that they will be
accepted by the average user.

hth
--
Bulworth : PHP/MySQL/Unix | Email : str_rot13('f@fung.arg');
--------------------------|---------------------------------
<http://www.phplabs.com/> | PHP scripts, webmaster resources
Jul 17 '05 #6

P: n/a

Senator Jay Billington Bulworth wrote:

now it works... apparently IE6
^^^

There's why it was a problem in the first place.

I've had to modify the login code on any number of sites since IE6

came out, for this exact reason. We used cookies for authentication on a lot of sites for a long time without issue, then came IE6, and things "broke," and users started complaining that they couldn't login. I don't understand the supposed logic any more than you do. "Let's require a new header before we accept cookies. Meanwhile, anyone can send this header at will, regardless of their actual privacy policy." Yeah, that's really reassuring.

Worse, in many cases IE6 _still_ won't accept a cookie even after receiving the P3P header, if the user's "Privacy" setting is above "Medium High." Naturally, the end user who stumbles upon this setting sets it to the highest level, not paying attention to the tooltip about how it's going to block everything, because they're pumped full of fear about spyware and whatnot. It's driven me back to preferring .htpasswd based authentication, and while I still use cookies heavily, I no longer assume that they will be accepted by the average user.

hth


Well, I agree that it seems pretty stupid...

What I *don't* get is why it works on the production server (the
windows box)?!? I mean, I type in http://production.server from the
same computer & same browser & the site pops up. I type in
http://new.server & it was screwed up - same code on both boxes. I've
gone through all the code that seemed relevant & I can't see that they
coded anything to be dependant upon a hostname or server name... if
that were the case, I could understand the difference between machines
- but I can't find that they've done anything like that. Is there a
major change between php 4.0.6 & 4.3.x in the way cookies are handled?
Granted I don't know a lot about cookie generation, so I may be talking
out my nose here.

I don't know... seems to be working now, but it sure caused for a long
night.

Jul 17 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.