Geeklog Forums

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!!!

(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). bye, Dirk

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. bye, Dirk

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!

---

Friends help you move. Real friends help you move bodies.

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. -Jason

Me again... 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. -Jason

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 conversation.

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:// forums.mercuryboard.com/index.php?a=topic&t=697

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.
Jann

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.

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). Humbly, Jann

fyi - Apache 2 and php 4.2.2 don't even compile together as of today.

This was sent to bugs but i thought it needed to be cross-posted here anyway:
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 & #36;_SESS_VERBOSE = 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: 1212562229
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- common.php
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 cookie.
***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 & #36;userdata (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 like this because
// it's suppose to be a global variable. I tried setting $_USER from within
// 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 < b>NOT TO!)
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. < br> $_USER['username'] (in $msg) is not being substituted in lib- common (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 set INSIDE the function and not outside as previously stated in the script as being required.

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

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?

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

---

Friends help you move. Real friends help you move bodies.

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!

---

Friends help you move. Real friends help you move bodies.