52
Probably a dumb question, but does XOOPS 2.0.18.1 run on php5.x ?
Another dumb question - How do I set XOOPS to run in debug mode, with no admin ? That is, what field/s in the db need to be tweaked ?
I can deny all IP's, except mine, whilst it is in debug mode.
Another dumb question - How do I set XOOPS to run in debug mode, with no admin ? That is, what field/s in the db need to be tweaked ?
I can deny all IP's, except mine, whilst it is in debug mode.
53
Quote:
I will try that, and let you know.
Quote:
That value is off as a system wide thing, and phpinfo() says the value is off/zero
If I do this -http://example.com/modules/protector/admin/index.php
I get a msg "only admin can access this area" . That comes from /modules/protector/admin.php (in the 'trust' path), code as follows
which could even just mean that XOOPS, despite the fact that I get a msg saying I'm logged in, may not even think that I'm a 'user' ?
If there was some way to re-install protector, just in case it is protector that is stopping all this.
With a considerable number of attempts on the website, I'm hesitant to remove protector of course, even if just for a brief moment.
Pete
ghia wrote:
Did you test your test script also from another directory(eg /modules/news/)?
I will try that, and let you know.
Quote:
ghia wrote:
Try also to setphp_value session.use_trans_sid 0
That value is off as a system wide thing, and phpinfo() says the value is off/zero
If I do this -http://example.com/modules/protector/admin/index.php
I get a msg "only admin can access this area" . That comes from /modules/protector/admin.php (in the 'trust' path), code as follows
// check permission of 'module_admin' of this module
$moduleperm_handler =& xoops_gethandler( 'groupperm' ) ;
if( ! is_object( @$xoopsUser ) || ! $moduleperm_handler->checkRight( 'module_admin' , $xoopsModule->getVar( 'mid' ) , $xoopsUser->getGroups() ) ) die( 'only admin can access this area' ) ;
which could even just mean that XOOPS, despite the fact that I get a msg saying I'm logged in, may not even think that I'm a 'user' ?
If there was some way to re-install protector, just in case it is protector that is stopping all this.
With a considerable number of attempts on the website, I'm hesitant to remove protector of course, even if just for a brief moment.
Pete
54
It seems session.use_only_cookies makes no difference at all. I have it included in mainfile.php, yet somehow XOOPS doesn't think that I'm logged in, or it does think I'm logged in and won't let me access admin, or set the XOOPS defined cookie name.
I even ran another script, to include mainfile.php, and display phpinfo() , and session.use_only_cookies is definitely getting set on.
Pretty frustrating. If it was a php error, there would be errors in the logs file, but there are none. Very difficult to pinpoint the cause of the problem, with no apparent reasons. :(
Pete
I even ran another script, to include mainfile.php, and display phpinfo() , and session.use_only_cookies is definitely getting set on.
Pretty frustrating. If it was a php error, there would be errors in the logs file, but there are none. Very difficult to pinpoint the cause of the problem, with no apparent reasons. :(
Pete
55
Quote:
Yes, if I used php.ini, I would have to have it in every path where a script is executed. I did try modifying it, but the value I changed did not make any difference. That said, I would have to make sure that all the /include paths , etc had the same (modified) php.ini file.
I can't use the 'php flag' in .htaccess. If I could that would be great. From memory, it can't be used for php flags if phpSuexec or something like that is used.
Pete
ghia wrote:
For the modified php.ini, most servers want this in every script directory. It is in general not inherited to the subdirectories, as access allow/deny does. You can use a .htaccess file to simulate a copy in all directories.
Yes, if I used php.ini, I would have to have it in every path where a script is executed. I did try modifying it, but the value I changed did not make any difference. That said, I would have to make sure that all the /include paths , etc had the same (modified) php.ini file.
I can't use the 'php flag' in .htaccess. If I could that would be great. From memory, it can't be used for php flags if phpSuexec or something like that is used.
Pete
56
Quote:
Even if I login with the 'www', XOOPS logs me in, and the url changes to domain name without the 'www'. I have the dns records setup to accept both.
Quote:
No, I don't have that sort of control over the website. It is a shared server.
Quote:
Yes, I have Protector, but I can't access it, as it appears under admin. I have it installed outside the web root of course.
This may be the database, I don't know ? I thought there was an easy way to check (just compare the sql export data to a previous one), but the format of the sql is quite different, from version to this one.
I have chaecked a few things in the db, like make sure that 'admin/webmaster' has the correct perms here and there. All are set to value of '1'.
Thanks for your help,
Pete
PS It may be 'easier' for me to upgrade to the latest XOOPS, although there are various modules that may have moved on, or changed somewhat.
ghia wrote:
It is not a question of accessing the site with an URL with or without www?
Even if I login with the 'www', XOOPS logs me in, and the url changes to domain name without the 'www'. I have the dns records setup to accept both.
Quote:
ghia wrote:
If the PHP version was changed, could you reinstate/select PHP 4?
No, I don't have that sort of control over the website. It is a shared server.
Quote:
ghia wrote:
Do you have Protector? Try once to disable it in its preferences.
Yes, I have Protector, but I can't access it, as it appears under admin. I have it installed outside the web root of course.
This may be the database, I don't know ? I thought there was an easy way to check (just compare the sql export data to a previous one), but the format of the sql is quite different, from version to this one.
I have chaecked a few things in the db, like make sure that 'admin/webmaster' has the correct perms here and there. All are set to value of '1'.
Thanks for your help,
Pete
PS It may be 'easier' for me to upgrade to the latest XOOPS, although there are various modules that may have moved on, or changed somewhat.
57
Quote:
It strips it out ..
Sure does seem I was using an old file to check all the files. The checksum files are the ones to use then, not the MD5 files.
Quote:
The content of that file, both from the XOOPS 2.0.18.1 archive and from my local copy of the website show
Quote:
The file checksum.md5 is dated Sat 16 Feb 2008 19:39:10 EST , and file size is 40.6 KB (41616 bytes).
I have downloaded 2.0.18.1 from SourceForge, extracted it, and the only messages from running the checksum are ..
Quote:
It has been run on the website, and on my local copy of the website. The 2 files that are shown to be different there, robots.txt has been changed, and I had to modify /userinfo.php , as I didn't like guests being able to see the username of registered users. That file hasn't changed for a long time.
It's still a mystery, then.
Thanks,
Pete
ghia wrote:
Your file is probably wrong, because htdocs is not in the MD5 file of 2.0.18.1
Weird is that the htdocs doesn't show in your error messages.
It strips it out ..
if ( substr( $file, 0, 7 ) == 'htdocs/' ) {
$file = substr( $file, 7 );
}
Sure does seem I was using an old file to check all the files. The checksum files are the ones to use then, not the MD5 files.
Quote:
ghia wrote:
Verify the XOOPS version in /include/version.php
The content of that file, both from the XOOPS 2.0.18.1 archive and from my local copy of the website show
<?php
// $Id: version.php 1236 2008-01-08 23:00:25Z phppp $
define("XOOPS_VERSION","XOOPS 2.0.18.1");
?>
Quote:
ghia wrote:
It should be dated of 16/02/2008 16:39 and having 41.616 bytes.
Refer to SourceForge for a copy of the archive.
The file checksum.md5 is dated Sat 16 Feb 2008 19:39:10 EST , and file size is 40.6 KB (41616 bytes).
I have downloaded 2.0.18.1 from SourceForge, extracted it, and the only messages from running the checksum are ..
Quote:
./robots.txt content invalid
./userinfo.php content invalid
./install/index.php missing !
./install/install_tpl.php missing !
./install/makedata.php missing !
./install/passwd.php missing !
./install/style.css missing !
./install/class/cachemanager.php missing !
./install/class/dbmanager.php missing !
./install/class/mainfilemanager.php missing !
./install/class/settingmanager.php missing !
./install/class/textsanitizer.php missing !
./install/img/bg_content_left.gif missing !
./install/img/bg_content_right.gif missing !
./install/img/bg_darkblue.gif missing !
./install/img/bg_table.gif missing !
./install/img/dummy.gif missing !
./install/img/hbar_installer_right.gif missing !
./install/img/hbar_left.gif missing !
./install/img/hbar_middle.gif missing !
./install/img/hbar_right.gif missing !
./install/img/logo.gif missing !
./install/img/no.gif missing !
./install/img/xoops2.gif missing !
./install/img/yes.gif missing !
./install/language/english/finish.php missing !
./install/language/english/install.php missing !
./install/language/english/install2.php missing !
./install/language/english/mysql.lang.data.sql missing !
./install/language/english/welcome.php missing !
./install/sql/mysql.data.sql missing !
./install/sql/mysql.structure.sql missing !
./install/sql/upgrade/mysql.structure.sql missing !
There are 623 files checked.
Please remove the file ./checksum.md5 and checksum.php as soon as possible.
It has been run on the website, and on my local copy of the website. The 2 files that are shown to be different there, robots.txt has been changed, and I had to modify /userinfo.php , as I didn't like guests being able to see the username of registered users. That file hasn't changed for a long time.
It's still a mystery, then.
Thanks,
Pete
58
I uploaded the 2 MD5 files, and ranhttp://example.com/xoops_md5.php
The output was full of this type of errors ..
Quote:
I'm using version 2.0.18.1 of XOOPS, and I assume the correct MD5 files are being used. Funny thing is, only a few days ago, I compared all the XOOPS files to a recent website backup, and all returned an equal on compare ??
The XOOPS MD5 files does have this prefix for all the files ..
===
htdocs/admin.php:ea883acad4c4ee5983cdaaef2491134f
htdocs/backend.php:c37971e12b8c779a8ae63c3882bc4b04
htdocs/banners.php:0b2a632d50abb9f7fdf08218a15da2c9
=======
but I assume the php script is clever enough to work out that the path 'htdocs' isn't there.
As I run a Linux box here, I also ran php on the files, using the XOOPS md5 script, and got the same error messages. Will need to find a backup of 2.0.18.1 , just to be sure these md5 files are _for_ 2.0.18.1
Pete
The output was full of this type of errors ..
Quote:
admin.php content invalid
backend.php content invalid
banners.php content invalid
class/auth/auth_ads.php content invalid
class/auth/auth_ldap.php content invalid
class/auth/auth_provisionning.php content invalid
class/auth/authfactory.php content invalid
I'm using version 2.0.18.1 of XOOPS, and I assume the correct MD5 files are being used. Funny thing is, only a few days ago, I compared all the XOOPS files to a recent website backup, and all returned an equal on compare ??
The XOOPS MD5 files does have this prefix for all the files ..
===
htdocs/admin.php:ea883acad4c4ee5983cdaaef2491134f
htdocs/backend.php:c37971e12b8c779a8ae63c3882bc4b04
htdocs/banners.php:0b2a632d50abb9f7fdf08218a15da2c9
=======
but I assume the php script is clever enough to work out that the path 'htdocs' isn't there.
As I run a Linux box here, I also ran php on the files, using the XOOPS md5 script, and got the same error messages. Will need to find a backup of 2.0.18.1 , just to be sure these md5 files are _for_ 2.0.18.1
Pete
59
I added this line to mainfile.php
However, it made no difference at all, same problem, no admin access. :(
@ini_set('session.use_only_cookies', 1);
However, it made no difference at all, same problem, no admin access. :(
60
If it is the session setting, then can it be set in a php file that XOOPS accesses all the time ?
Like in /include/common.php , just where a user logs in, we have
So, in theory, we could have an extra line there at the top of the login ..
Surely other people must have this problem, as not every server can modify php settings via .htaccess (assuming that is the problem).
Pete
Like in /include/common.php , just where a user logs in, we have
@ini_set('session.gc_maxlifetime', $xoopsConfig['session_expire'] * 60);
So, in theory, we could have an extra line there at the top of the login ..
@ini_set('session.use_only_cookies', 1);
Surely other people must have this problem, as not every server can modify php settings via .htaccess (assuming that is the problem).
Pete
Login
Search
Recent Posts
Who's Online
Donat-O-Meter
| Stats | |
| Goal: | $100.00 |
| Due Date: | Apr 30 |
| Gross Amount: | $0.00 |
| Net Balance: | $0.00 |
| Left to go: | $100.00 |
 |
|