Doesn't work on PHP 4.3.2
Brought to you by:
leo_west
Menu
▾
▴
#16 Doesn't work on PHP 4.3.2
Having succesfully installed the PHP application, and
trying to log in using the master account webo-adm and
password webo-adm ; when clicked on Sign In, you
are "redirected" to the same login page again. It doesn't
log in. When entering a different user/pass; it tells you
bad user/pass.
Magic Quotes are set to off in the PHP runtime
environment, Sessions are enabled.
Could this be a bug?
PS: The Install FAQ included in the 1.x package still
speaks over "installing version 0.3.x" and mentions a
empty password !
Good luck altering & thanks for sharing!
Submitted by filip@curious.be
Logged In: NO
Hi!
I got the same problem....
/MrAddee
Logged In: NO
Hi!
I got the same problem
Wolfware
Logged In: YES
user_id=809916
I'm getting the same problem with a Red Hat 9 install with
PHP 4.2.2
Logged In: YES
user_id=809916
From the log files:
httpd: [webo] Error in lib.mysql.php [1054] Unknown column
'task_user' in 'where clause' user=webo-adm appcode=
httpd: [webo] autologin disabled user=webo-adm appcode=
httpd: [webo] authent verified OK user=webo-adm appcode=
httpd: [webo] webo session started user=webo-adm
appcode=session.start
httpd: [webo] Webo::checkAuthent : false user= appcode=
httpd: [webo] timer timer.page : 0.007 secs user= appcode=
Logged In: NO
I have the same problem.
Php 4.3.2 + apache 1.3.27
Runing on RH 7.2.
Emiliano.
If you solved this, mail me: the_emito@yahoo.com.ar
Logged In: NO
I'm having exactly the same problem, running on RH 9 with
php 4.3.2, apache 1.3.x
- Yaron
Logged In: YES
user_id=339412
It appears that all the references in User.php should be
changed from "task_" to "auto_". This still does not correct
the greater issue of redirection from signin.php to signin.php.
I have tried several of the PHP.INI options that I know have
changed between releases. These did not correct the problem.
More than likely, it involves the changes to some of the
PHP.INI options that are treated differently in this release
(i.e. register_globals...session.auto_start...etc).
Hope this helps.
Logged In: NO
Setting register_globals = On in php.ini helps!
Still some other bugs though with QUERY_STRING...
bobd
Logged In: NO
PHP 4.3.3
Login with webo-adm, pwd: webo-adm, returns same login display. Log shows this:
Webo::checkAuthent
enableAutoLogin()
Error in lib.mysql.php [1054] Unknown column 'task_user' in 'where clause'
autologin disabled
authent verified OK
abook_session_start : creating AddressBook webo session started Webo::checkAuthent : false timer timer.page
Logged In: NO
A little more progress made on this login issue:
user.php and autotasks.php reference task_user in automatedtasks, but task_user has been renamed to auto_user. DOH! Fixing this, I still get the same problem. Here is the log...
Webo::checkAuthent : false
timer timer.page : 0.059 secs
Webo::checkAuthent
enableAutoLogin( )
authent verified OK
abook_session_start : creating AddressBook
webo session started
Webo::checkAuthent : false
timer timer.page : 0.061 secs
Logged In: NO
Did anyone fix that problem, or should I just erase my install
dir. right now, and move on?
Logged In: YES
user_id=706952
Hi folks,
it looks like hitting the delete key will be the right function.
In the support request section there are more people with
the same problem, it is going on now for half a year.
So far there is no real answer. I feel that loggin in is a rather
useful and basic function, which should work. Nobody wants
to wait for half a year to use a program. So meanwhile I
don't care what wounderful pages might come up in some
time.
Good luck with the bug.
Logged In: YES
user_id=156822
File: webo-patch-002-signin.tar
Date: Fri Nov 21
Description: This patch will hopefully correct the bug #749383
(redirection on the signin page)
Installation
cd /home/webspace/webo
tar xvf webo-patch-002-signin.tar
bug fix
Logged In: NO
Hi Leo,
sorry it does not work, I get onto the redirect page and
within seconds I am back at an empty login page.
It seem that there is a correct loggin, and going into the
webo area you are signed off again.
Again wrong users give a correct answer
Good Luck
Florian
Logged In: YES
user_id=961906
Is there a work around yet? I notice this call has been open
for a long time. I'm trying to figure it out by studying
the code, and it appears that for what ever reason, the
instance of the 'user' class dispappears.
I've set the register_globals to on, but I don't see a
declaration that the user instance *is* global.
Has everyone else given up on this app?
TIA
Brian
Logged In: YES
user_id=706952
Hi Brian,
I gave up on the problem. It is working on my www.server,
but not at home. Leo got in touch with me, but of course he
can't access my home computer.
Leo is loocking for somebody, where he could have a grip
onto the problem. So he could step through it and do further
checks.
So if you are running an open server, write to Leo, I think he
would like help and to get rid of the problem.
Best regards
Florian
Logged In: YES
user_id=961906
I fixed it!!!!!
The documentation says the php.ini file lives in
/etc/php.ini. And that is where you find it. However, if
you create a dummy page with
<?php phpinfo(); ?>
you find out where php *really* is looking. In my case, it
was looking in /usr/local/lib. Once I copied the php.ini
file there, I was able to log in!
I hope this helps others.
Going on to test the rest of the application now.
Good luck
Brian
Logged In: YES
user_id=961906
oops, it ate my code.
php phpinfo()
that will tell you where it is actually looking for the
php.ini file
Logged In: YES
user_id=819078
Hy,
I got the same problem : return to signin.php;
Access to database is ok.
php.ini ok
patch is applied.
The authentification process works fine until the function
startsession is called in the signing.php (line 91)
Then there is an object test ($user) performed by Webo.php
(line 94). At this step the object is no more available and
the system send you back to the signing.php page.
Hope it can help
nicolas.rollin@objclt.ca
Logged In: YES
user_id=961906
Greetings,
First, you must set register_globals to on, by default it is
off.
Second, verify the path to php.ini. Create a test page that has
a phpinfo() in it. This will tell you the exact location
that php expects the php.ini file. The documentation says
/etc, but, when I excuted the test program, mine said
/usr/local/lib. Very important that you verify this
information.
Help this helps,
Brian
Logged In: NO
Brian,
thank you It's working. accept I don't like running with
Cregister_global on.
That's a nice application
Thanks for your time,
Nicolas
Logged In: YES
user_id=706952
I just got frustrated and dumped the entire instalation. For a
while, it was working, then suddenly I could not log in, today
again I was able to log in correctly. I have no idea what is
going on, and the problem goes through for more trhan a
year.
Could it be a cooky problem?
Good Bye
Logged In: YES
user_id=976960
Just tried the install - get to the login screen. It does
inform me of an invalid password. A good password, and the
login just redisplays. Looks like a change in progress, as
my /var/log/messages has:
Feb 16 11:52:12 cogs httpd: [webo] Error in lib.mysql.php
[1054] Unknown column 'task_user' in 'where claus
e' user=webo-adm appcode=
Feb 16 11:52:12 cogs httpd: [webo] autologin disabled
user=webo-adm appcode=
Feb 16 11:52:12 cogs httpd: [webo] authent verified OK
user=webo-adm appcode=
Feb 16 11:52:12 cogs httpd: [webo] webo session started
user=webo-adm appcode=session.start
Feb 16 11:52:12 cogs httpd: [webo] Webo::checkAuthent :
false user= appcode=
Feb 16 11:52:12 cogs httpd: [webo] timer timer.page : 0.004
secs user= appcode=
Logged In: YES
user_id=161436
The problem is that WEBO assumes register_globals = On. All
the current versions of PHP that I am aware of now default to
register_globals = Off (which is a good idea).
You have a couple of choices to solve this.
1. Change the WEBO code to not require register_globals be
On, That is what I plan to do if I decide to continue using
WEBO. No really a trivial thing to do, but not too hard either.
2. Add register_globals = On to an .htaccess file within the
webo directory structure. That is what I have currently in
place. That allows my other apps that do not require it to
function correctly. You just need to create a .htaccess file
with this line in it.
php_value register_globals Off
3. Change the register_globals value in your php.ini file. On
most Linux distributions this is at /etc/php.ini
There are a few other ways to do it such as importing all the
globals for $_POST and $_GET, but if you are going to do that
you might as well just fix WEBO.
Bob