I am wondering what the exact need for making the permissions on the directories:

cache/
templates_c/
uploads/

so liberal.

I recently had a malicious user insert a redirect statement in

uploads/

that initiated a phishing scam that prompted some angry emails from a very large bank.

I have found other similar phishing scams inserted into all three directories.

What would be a good way to prevent this happening again?

Sam Bowen

I actually solved this myself. I made a couple of errors in the transfer of the XOOPS site.

I had a trailing slash on the path definition:

define('XOOPS_ROOT_PATH', '/webpath/xoops');

Getting error reporting working was tricky. None of the errors were being displayed and I had the dread "blank white page".

Eventually I realized that

XOOPS 2.2.3

requires a different command to turn on error reporting than the "recommended" versions.

After getting error reporting turned on I discovered that I had not correctly set the permissions on:

xoops/templates_c

directory.

Everything now appears to be fully functional.

Sam Bowen, MD

I am in the middle of upgrading my server to new machine, new operating system and am trying to migrate the existing XOOPS 2.2.3 site to the new server.

My current server is running FreeBSD 6.1, Apache 1.3x, MySQL 4.1.18, PHP 4.4.4, XOOPS 2.2.3.

The new server is running FreeBSD 6.2, Apache 2.2, PHP 5.2.3 with Suhosin-Patch 0.9.6.2, MySQL 5.2.

I am migrating the old XOOPS to the new server which has a new path. I know the XOOPS version is old and needs to upgraded. I was planning to do this after moving to the new server.

Which lines in mainfile.php and which other files need to changed to effect this type of change?

Sam Bowen

I was able to manually repair the affected users. I did install phpMyAdmin to do the following:

table

users set level = 1
user_profile set posts = 1
user_profile set user_regdate = 1152705600 (the unix date of registration)

I then entered the extended profile of the affected user and gave them a group select of Registered Users.

After this the user behavior appears to be normal.

Still, Why does the registration routine allow this to happen in the first place?

Sam Bowen

“Also, just so ya know, the latest version in the 2.2 branch is 2.2.4. Try upgrading your system to that version as well.”

The 2.2 branch is problematic. A lot of the modules do not function correctly. In fact I wonder if this registration behavior is not a problem with the 2.2 branch. I intend to roll back to the 2.0.14 branch when I have a rainy day to work on it. This rollback will not work with 2.2.4 so I have stayed with 2.2.3 for a while. I am waiting on the development team to make some progress towards fusing the two branches into 2.4. If they do not make enough progess towards 2.4 (or abandon 2.2) then I will roll back to the 2.0 branch. Either way, upgrading to 2.2.4 is not likely going to fix this problem.

It seems that more experienced users are the ones who have trouble with the registration. As stated later in this thread, mistakes made during the registration process seem to be causing the problem and would explain the erractic behavior.

All inactive users appear to have a level 0. Where the active users have a level of 1. Unfortunately simply promoting the inactive user from level 0 to level to level works only if the number of posts = 0. If the number of posts shows -1 this does not fix the users status. (I've already tried this).

I understand that Unix time zero is shown as midnight of 1970-01-01 (or on some systems as 1969-12-31). I stated this in my post in the forum #231902. I take this to mean that the existing add user function is passing a null value to the “date joined” field. This should not be allowed to happen and represents a bug in the add user function.

Deleting the user accounts doesn't work. I've tried this also. When I go back in to receate the account using the same user name and e-mail address the account is still broken.

The anonymous users already have access right to the extended profiles.

The thread #43591 is definitely discussing the same problem but there does not appear to be any clear solution other than using a manual deletion. It appears that this add user function updates the database with incorrect information before the user is able to verify that the information thereby, breaking the registration process.

Does this ever happen in the 2.0.14 (stable) branch?

Sam Bowen

I am currently running XOOPS 2.2.3 on a production server and have been experiencing intermittent difficulties with some of my users not being able to complete registration. They will show up as a inactive user, date joined 1970-01-01, with number of posts (-1).

Are there any thoughts on what causes this behavior and how I can get it to stop?

Can I complete/repair the activation of these users manually?

Thanks,

Sam Bowen

In Unix/Linux time begins 1970-01-01. A Date of 1970-01-01 usually means that the date field was left empty and is either null or zero.

I appreciate the feedback. I especially appreciate the link to the earlier discussion of 2.2.* and 2.0.*. It still represents a tough decision: “To rollback or not to rollback, that is the question. Whether tis safer to hold tight and wait on 2.4 or to rollback to the stable branch 2.0.13.2.

I t explains a lot. I was having a lot of trouble getting many of the features on the modules to work and this explains why.

I installed wiwimod, tiny content, cjay content, and newBB. Many of the features were broken and while I got newBB installed none of the users could access the bulletin board. I have not yet been able to figure out how to grant the registered users access.

I have installed both 2.2.3 and 2.0.13.2. Having the most commonly used modules already pre-installed is very useful. From the viewpoint of a new/inexperienced XOOPS administrator I wish I had seen the instructions about 2.0.13.2 being the stable production version before preceding with my first installation.

Any wild guesses about when the two forks will merge back together into 2.4?

I have realized since iniating my production site (2.2.3) a few months ago that indeed a number of of the modules do not owrk correctly or are difficult to install under 2.2.3.

It seems that I would be better off with the more stable 2.0.13.2.

I understand the concept of applying patches to upgrade to the most recent version. I have not been able to find a descrition of a way to roll back a site to an earlier more stable line. (2.2.3 --> 2.0.13.2)

I don't mind copying and pasting the existing pages. I am more concerned about maintaining the registered users already accumulated.

I had in mind installing 2.0.13.2 as a new website

webroot~/xoops-2.0.13.2/

copying the involved pages from the original site

webroot~/xoops-2.2.3/

to the new site.

Then transfering the users from the first installation to the second installation using a PHP script and a couple of SQL statements:

Select user1 from xoops_users-2.2.3;
Insert user1 into xoops_users-2.0.13.2;

I would appreciate information on a recommended rollback procedure or other addittional thoughts on this matter.