php upgrades

I recently upgraded from ver 4 to 5 using the script in the wiki. But I found out there is a small problem. I think it has to do with sessions.
Is there anything in the php.ini file that I absolutly have to change to get my guestbook working.
The problem has to do with authorizing the administration page. When switching back to ver 4, I can log into the admin page just fine. So it must be the upgrade that is causing the problem. Both versions are cgi btw.
thanks,
Silk

How did you login?

The script using register_globals? ^_^
Or register_long_arrays?

Both of those are turned off in PHP5. Everybody talks about register_globals, but forget about register_long_arrays, too.

to be honest I am not sure how the script works. I think it is using classes. The script uses a tremendous amount of external files. I personally think they did that just to make sure someone did not copy and sell their code.
Anyways, both globals and long arrays were left at default off in the php.ini file.
it seams to me awhile ago I saw a document that showed what values should be changed to make sure php is secure.
That is one of the reasons why I decided to post. though getting the guestbook working the way it was would also be a big help.
I want to make sure my website doesn't leave any big security holes for me or any one else on the same server.
The advanced guest book was created by http://www.proxy2.de/ if that is any help.
I see a bunch of others having a similar problem, so I may be onto the actual problem, as they may not have control over upgrades.
Another thing that came to mind, is the username and password are stored in the database. I am wondering if they are using pear to access the database. strike that last thought, I wouldn't see any data if that was the case.
I am half temped to try and write my own guestbook.
Silk

I hadn't used guestbooks in years.

The issue can be any number of things. Have you turned on errors to see if it's spewing something you're not seeing? Default configuration turns off display_errors. log_errors should be on, so maybe check the error logs?

I've noticed some oddities with E_STRICT on my local system where regardless what I set display_errors to, it never displays errors (just a blank page). Peeves me off. So I had to set error_reporting to E_ALL.

Just some avenues to check. It does appear, from you say, that this script just is not PHP5 compatible. This is extremely common and not surprising at all. PHP5 broke many scripts, and not just with register_globals or register_long_arrays.

Are you sure that this is related to session? I'll wager you're having the same problem I did when I migrated to PHP5. Essentially my issue was related to the tightening up of variable scopes. My action pages looked for submitted fields without a scope.
Example:
if ($loginName) {
setup the session junk...
}

After upgrading I had to change all of my URL variable references so they looked like this:
if ( isset($_REQUEST['logout']) ) {
clear the session junk...
}

All of my form POST variable references had to look like this:
if (isset($_POST['login']) && isset($_POST['password']))
{
setup the session junk...
}

Before I found this it simply appeared that the session wasn't getting configured properly. In reality the problem was that the conditional code never got executed in the first place.

Hope this helps.

BC Tech
Team Shocker

In reply to:

---

In reality the problem was that the conditional code never got executed in the first place.

---

You actually ran into a register_globals problem.

$loginName -- that is a register_globals variable. That's very well known issue in the PHP community. Too many people didn't properly develop their scripts. ^_^

fyi, it's HIGHLY recommended NOT to use _REQUEST unless you absolutely have to. If the value is always in the query string, use _GET. If it's always in POST data, use _POST. Try to keep away from _REQUEST if you can.

Thats a good thought about turning on error reporting, I have a tendency to forget things like that. lol.
As for using isset, I normally use that in my own codes or use booleans, but this script uses classes and I haven't learned that portion of php yet. This script is extremely comfusing trying to figure out what goes where. I prefer lateral type programming, much easier to guess what comes next.
Sometimes I wonder if guestbooks are really worth it. Not long ago I had to write a capcha for it to stop the moron bots.
Anyways, thanks for the replys.
Silk

I just noticed on the one click installs, that the advanced polls is broken in php 5. So you may be right. I posted a meesage on their forum, maybe the author has an answer.
Silk

I just picked a variable name adhoc, and didn't realize it was reserved. I was trying to illustrate the use of naming without scope. Mine is working, but I actually called username.

Thanks for the tip about request scope, I didn't know it was a problem. I wasn't aware that a url with a query string appears the same as a form submitted by way of the get method.

If you would be so kind, could you lead me to further research about the request scope? It's got a clearly defined purpose within Cold Fusion, but PHP is evidently a different animal.

Thanks again,
Ben

BC Tech
Team Shocker

In PHP, they aren't known as "scopes", they are "super globals." Specific arrays which have a global scope, reguardless where you are in your script.

You can read all about them on PHP's site: http://us2.php.net/manual/en/language.variables.predefined.php

_REQUEST is a combination of _GET, _POST and _COOKIE. It's really an ugly beast and should only be used if you expect if you really don't know which array your variable is coming from.

On top of all that, based on your posted code, be very, very careful when using the arrays directly. Remember, just because your form requires "name" it does not mean that your _POST key value will be "name." If you get what I'm saying.

In reply to:

---

This script is extremely comfusing trying to figure out what goes where. I prefer lateral type programming, much easier to guess what comes next.

---

OO vs procedural programming. ha
Personally, I prefer the OO method. It's actually extremely simple once you understand it. My background was in C++ programming, so when PHP came OO, I leapt on it! PHP's OO design is very much like Java's, which is another language I learned just before I moved to PHP5, which made things so much easier. Play around with it, you'll understand it. OO, at it's core, is extremely simple.

Yeah I know sooner or later I will have to learn OO. I been wanting to get into visual C++ for quite awhile. I haven't given Java much thought yet.
Silk

You're better off jumping into Java than Visual C++. Two reasons: (1) C++ is "hack job" OO built onto top of C. It's OO by design, but it's still a bit of a hack job. (2) Java is 100% OO. Even a single file application has to be a class to run.

Visual C++ is also an issue. That's the IDE writing the code, not you. I'd recommend Java and Eclipse. The Eclipse IDE is by far THE best IDE for Java (and thank god Zend's working on a PHP plugin for it).

But, in all honesty, you can learn OO design from PHP (just not as strict as Java). PHP's OO is much like C++'s OO. It's a hackjob onto the language. It'll work, but it's not a "pure" OO language since you can still write in procedural code.

I checked that forum too, and the reason Advanced Poll doesn't work for PHP 5 is that the default value of a variable changed from PHP 4 5o PHP 5. If in php.ini, this variable could be set:

register_long_arrays = on

then it would work. Has anyone tried asking DH support to change this variable setting from off to on? I don't know if it's an issue to change it.

Bad idea to have it on. That's why it's off. Register_long_arrays is what gives you your HTTP_*_VAR's. It's better to use _SERVER and _ENV than register_long_arrays.

I figured it had to do with register_globals or register_long_arrays. Too many scripters improperly relied on those variables.

Thanks for the info about register_long_arrays; I suspected it was off for a reason. I'll go to the Advanced Poll forum and ask if there are any plans to recode so it isn't needed... somehow I doubt it!