Subject: Is there a reason?
Posted on: 23/07/02 01:15am
Is there a reason that even though apache.org states the following:
The Apache HTTP Server Project is proud to announce the third public release of Apache 2.0. Apache 2.0 has been running on the Apache.org website since December of 2000 and has proven to be very reliable. (KEEP IN MIND THIS IS 1.5 years now!)
PHP and Geeklog Dev. Team has IGNORED the Apache2 issues. Also, I honestly believe that the answers we get here about "PHP is not to be run on a production site with Apache2" are ignoring the fact that maybe, just maybe, Geeklog is using a nonstandard method of either reading or writing the cookies and sending out the correct information to the browser. How many of us 'geeks' dare to say that we do not run production sites even though they are only hobby sites!? They are PRODUCTION to US!
Also, I would like to remind the general Geeklog public-at-large that there is a HUGE security flaw in Geeklog with respect to requiring register_globals = On! http://www.php.net/ has issued this formally!
Is it just me or is the normally "outstanding" Geeklog development team ignoring most of these issues?
Can we start a conversation about some of this?Maybe, especially, changing Geeklog to use session handling via URLs OR COOKIES, dependant upon the wishes of the Geeklog administrator(s). Actually, session handling using URLs would eliminate the issues we are all facing when running under Apache2!!!
Posted on: 23/07/02 04:49am
(I'll split my response in two, since your post touches two separate issues)
Sorry, I fail to see the point in this. Apache 2 has only been released for production sites in May this year (not in 2000). The PHP developers state that PHP for Apache 2 is still experimental. Now how exactly is this the fault of Geeklog or it's developer team?
In my opinion, it does not make much sense to try and track down problems which Geeklog might have in an Apache 2/PHP environment when you can't be sure if the problem is with PHP or with Apache.
If you find any problems with this setup and you can show that they are Geeklog's fault, then we will be happy to accept your suggestions. Until then, I at least will concentrate on addressing issues that the majority of Geeklog users have - and nearly all of those are in environments with Apache 1.3.x (or other web servers).
Posted on: 23/07/02 04:51am
Now for register_globals=on: It has been stated here a couple of times (please use the search function) that we are aware of this issue but that we chose not to fix it in the 1.3.x branch. Instead, Geeklog 2.0 will be built from the ground up so that it does not require register_globals=on.
Why? Because the Geeklog code is a couple of years old and hasn't been built with register_globals=off in mind. Because of that, lots of changes to the code would be required. This will bring with it the risk of introducing errors in code that worked fine before. Testing all those changes would require an enormous amount of time and manpower. Since we see the end of life coming for the 1.3.x branch anyway, it makes much more sense to invest our precious (and, may I add, unpaid for) time into a new and improved Geeklog which does not have those shortcomings from the start.
Besides, the security issues with register_globals=on are somewhat exaggerated. The example on php.net is valid, but it's an example of bad code, too. Coding security features like in that example is really careless.
I would be interested if you have found any problems in the current Geeklog code that can be exploited just because register_globals=on.
Is there a reason?
Posted on: 23/07/02 07:01am
Welcome to open source. Now, if you have an issue with this, then fix it! Grab the CVS code, and go through it with a fine tooth comb and see how you go.
Speaking for myself, it's not an easy thing to do. As soon as 4.2.0 was in pre-release, I looked into moving away from registered globals, but it was a huge job, and I think the v2 code *is* the best way to fix this issue.
Please, by all means, use your concern FOR the project!
Posted on: 23/07/02 08:32am
This is Jason, I can't log in...
PHP for Apahce 2 is expermental... This means NOT EVEN BETA! It's nice that geeks use geeklog for their sites but geeklog is also used for a few public, commercial and educational sites as well. Lets not go breaking everything just because.
BTW, if you want to run geeklog on Apache 2 and run in to problems why don't you fix them and sumbit diffs so we can patch the source.
Posted on: 23/07/02 08:35am
There is no reason that you can't fix the reqister_globals problem as you update the code. I've had to do that for several other projects as well. Of course, register_globals isn't a "real" security risk. Not checking user supplied information is the real risk.
Is there a reason? (cookies)
Posted on: 23/07/02 08:43am
So then, is there a major reason we do not use sessions? Is it simply
the combined "cos it is already there mentality"? Do not get me wrong.
I am a programmer and have contributed to open source and take pride
in the fact that I know what "cvs checkout" and "cvs commit" means...so
I am not just yelling for the hell of it...however, I just wanted an
I think there are going to be enough
incompatibilities introduced in the 2.0 version of Geeklog with all of the
blocks, feeds, plug-ins changes that we are going to burn SOMEone
regardless of whether or not we look at Apache2 NOW or LATER.
There is a history of PHP-4 and Apache2 in the last few
months directly affecting other PHP-cookie-based software and
those issues directly relating to how and where cookies are used, read
and written. Those issues have been repaired in other software packages
by rewriting the cookie sections. For information see: http://
So, As i
have said, a sessions (URL-based) system instead of all these DOZEN
cookies on the browser would make sense as an alternative...think?
Maybe a sessions (sessions.auto_start cookie) method is better.
What I WANTED was discussion, not dead-ends...that is all!
Dirk, to you I send my heartfelt thanks. You have really sent comments
to nearly all of my posts and it makes me think someone *is*
listening...but I wanted opinions about more than just APACHE2. I
wanted opinions about Geeklog development and fixes PRIOR to the
Geeklog 2 releases.
Thanks alot , btw.
Is there a reason? (cookies)
Posted on: 23/07/02 08:50am
Errr... no. If you wanted to talk about existing issues, you would have done so. Actually you just went on an ill-informed rant about Apache2.
1. 'Register_globals = on' does NOT, in itself, constitute a security risk.
2. mod_php for Apache 2 doesn't exist, as far as I'm concerned, until it gets out of beta. Right now it's barely alpha.
3. If you *really* want, use PHP as a CGI program. GL works fine (even on NT/IIS) like this. But it's not the smartest thing to do on *nix.
Is there a reason? (cookies)
Posted on: 23/07/02 09:57am
Ill informed rant?
Okay, then. Please let me know what is informed. I never said PHP was
beta, or even alpha....I SAID that there are those who use Apache2 as
production (BECAUSE it is released as such), and thus are lost without
PHP4 working under that scenario. There are THOUSANDS out there who
use PHP4 with their PHP scripts under Apache2 with no ill-effects because
they change their code to work smarter--not harder. IMHO Geeklog
does not work as smart as it could because you HAVE to have cookies on
in order to use it the way it was written to be used. How many posts
here say "I CAN'T LOG ON"? The ones REPORTING it are generally the
geeks who **RUN** it, not the users who **USE** it. This means there
are hundreds of people [not reporting it] that have their browser security
set too high or suffer the MSIE problem (MS wishing to control their
users' experience) and thus have cookies set to an impossible security
level. Those people cannot even log in to Geeklog. Where is the fix for
that? Are you seriously telling me that those users do not matter?
Geeklog is great! Geeklog is Good! Geeklog should run your
neighborhood. BUT just because Geeklog is running the neighborhood
association that your condo is in does NOT mean Geeklog should be
given a key to your house and instructions on how to walk your dog.
Really bad analogy but I hope you get my point. Not everyone CAN nor
WISHES to have cookie security set to LOW in order to accept cookies.
I just wanted to open discussion to find a better way. And YES, I will
look at the code to see how to fix it, however, I think I should not be the
only one looking to clean up the Geeklog 1.x series. There are, like i
said before, many people who, because of the radically different
direction Geeklog 2.x is going to take, cannot update and therefore will
need the 1.x fixes.
I hope you see this as constructive critisism and not as a rant (which i do
not mean it to be).
Posted on: 23/07/02 12:56pm
fyi - Apache 2 and php 4.2.2 don't even compile together as of today.
Is there a reason? (possible solution)
Posted on: 23/07/02 11:27pm
This was sent to bugs but i thought it needed to be cross-posted here
As a follow-up to the suggestion that I trouble-shoot this issue
(re:MLimburg): Has anyone noticed that upon login to the user.php
script, the following occurs (if you want to trace it, set &
= true; in your lib-sessions.php file and it will dump the following data
upon attempting to sign in).
This is how my trace looks:
USER CLICKS SUBMIT ON LOGIN BOX:
Tue Jul 23 22:44:03 2002 - *************inside new_session********
Tue Jul 23 22:44:03 2002 - Args to new_session: userid = 13, remote_ip
= 63.65.xyz.abc, lifespan = 7200, md5_based = 0
Tue Jul 23 22:44:03 2002 - Assigned the following session id:
Tue Jul 23 22:44:03 2002 - *************leaving SESS_newSession**
Tue Jul 23 22:44:03 2002 - ***Inside SESS_sessionCheck***
Tue Jul 23 22:44:03 2002 - session cookie not found from lib-
Tue Jul 23 22:44:03 2002 - ***Leaving SESS_sessionCheck***
I am tracing this methodically as follows:
You click login.
The system checks for a session cookie in lib-common.php
The system does not find a session cookie on the browser, either session
or permanent based.
The system exits this routine having gotten nowhere with identifying your
***Now, the interesting part:
THEN the system takes you to SESS_newsession which attempts to setup
a session in the database.
It has your id, ip, assigns a lifespan,etc
Now, it clears any session you may have had from the database AND
any session which timed out, inserts your session.
Then it sets a new cookie and sets the global $_USER to your &
(which holds your id, username, etc).
Now, in the past, we know we have had problems with this global.
According to the geeklog file lib-sessions.php (at the top):
// LOAD USER DATA. NOTE: I'm not sure why I have to set $_USER
// it's suppose to be a global variable. I tried setting $_USER from
// SESS_sessionCheck() and it doesn't work.
$_USER = SESS_sessionCheck();
Yet they are setting the $_USER variable from within this
SESS_sessioncheck routine upon login anyway. (like the script tells us <
WHY? is this the trouble we are all having who cannot log in?
Here is another interesting thought: the welcome_msg in header.thtml
gives us anoher clue: the variable substitution that does not happen. <
$_USER['username'] (in $msg) is not being substituted in lib-
(my line 343). (as read from $_USER hash/array)
YET our usernames are appearing in the upper right corner as being
logged in. (as read from mysql)
NOW, Please keep in mind that these things happen ONE AFTER
ANOTHER in lib-sessions.php and therefore can only be a of a failure for
the $_USER global to be set correctly due to the fact that it is being
INSIDE the function and not outside as previously stated in the script as
Any thoughts? Dirk? Anyone?
Keep in mind in am an experienced programmer--10 years,
however I just jumped into PHP a few months ago. I may be totally off-
base, but i CAN read code
Is there a reason? (cookies)
Posted on: 24/07/02 04:41pm
1. You do *not* have to set security settings to 'low' in any browser in order for cookies to work. The neophyte users you're talking about would have to figure out how to deny cookies in order for a problem to originate - unlikely to happen.
2. Almost every site on earth which requires logins does it with cookies. They don't appear to be having problems.
3. Session IDs screw around badly with URLs if cookies are off. Most site-owners prefer not to have URLs which run off the edge of the screen.
But all of that's moot. The plain fact is this: if you want to use PHP in a production environment, DON'T USE APACHE 2. Because it DOESN'T SUPPORT PHP YET. Clear?
Is there a reason?
Posted on: 25/07/02 10:44pm
Dude, PLEASE come into IRC!!! By the sounds on things, you could be of big help to the GL dev team, as we need to address these very issues, and we're pretty swamped with combining the need for bugs hunting/fixing plus building new features for our (almost) screaming users .. forums coming to mind.
Consider this an official invitation
#geeklog on irc.openprojects.net
Is there a reason?
Posted on: 25/07/02 10:51pm
Well, a couple of things come to mind. We should be using the PHP built session management system. The main reason to mind is it defaults to cookies, and if they're not available, uses URL based sessions. We would need to seriously look into this though as it *may* cause troubles ...
Now, the two main reason not to go 100% URL based sessions is a) bookmarking pages will save the session (minor thing as it auto-fixes), and b) URL SID causes additional server strain which could be unwarrented. When a site handles 5 users at a time, and 500 users a day, this is minor .. but if you have 500 users at a time, and 500,000 users a day (yes, I can think of an environment that would have this, and yes, the organisation is thinking about using GL for their service) then it's a REAL issue. The goal has always been to provide the optimal environment.
Now, having said that, we need to explore this issue further.
As I've said before, come into our IRC channel so we can discuss this realtime. Please! Or join the geeklog-devel mailling (see our project page on sf.net) and discuss it further. Please!
Geeklog - Forum