endless loop at Setup Manager

[brandon]

::taken from a previous post, I'm in the same boat::

I purchased the script, installed, and reached the setup manager where I created an initial login. I then logged in and was brought to a page asking to continue in trial mode or enter my order number. Upon entering number and hitting continue, I was brought back to the username and password entry screen. When I login, I am brought back to the "Enter order number" or continue in trail screen. Can't get out of that loop.

Brandon

[Brian]

Please make sure that all of the files in the root calendar directory (calendar.php, config.inc.php, license.php) are uploaded in ASCII mode.

[brandon]

Brian,

Happen to have another idea? I re-uploaded the files, still kicking me right back to setup manager from the license manager page (typing in order number)

Brandon

[ve9gra]

Check the licence.php file to see if the information you've entered was saved. If it isn't make sure that the appropriate permissions are set.

[brandon]

I re-uploaded the files. Changed permissions to 777 (from 646). Still kicks me right back to setup manager.

Looking at the license.php file, info is not being written to it. I do see the user I created in the config.inc.php file.

[Brian]

If you save the license.php file to your computer and open it in a plain text editor, dose it appear all on one line or on separate lines?

[brandon]

The code is on seperate lines.

[Brian]

And you had no issues with this when running the trial?

[brandon]

Exact same issue with the trial. (the price made it a no-brainer to purchase it after vieweing the online demonstration)

[kryptronic]

Hello all. This is brandon's server admin. I just uninstalled and reinstalled and we're in the same boat. I've checked PHP, IonCube, Permissions, etc. and am still experiencing the same issue.

It appears the program is not maintaining login state from page to page. I have identified that the PHP Session ID is not changing (as it shouldn't be). After every post the program reverts back to the login screen.

I manually edited license.php including all the appropriate info so now we can get past registration but upon clicking any link or submitting any form in admin the login page is presented.

I have confirmed 100% of the permissions are set to 777 on everything in the enter /calendar directory. I have chowned to user 'nobody' as well as brandon's server account as well. Note: Apache on this server runs under 'nobody'.

This is standard plain vanilla run of the mill LAMP (linux, apache, mysql, php) architecture. The box is Fedora Core 2 running Apache 2.0, PHP 4.3.8, IonCube 2.5. Don't ask me to change anything server side - it's good - plenty of Perl and PHP apps run on it daily.

I know what I'm doing here. Check out www.kryptronic.com for a sample of what I do. There is something seriously wrong with this install.

[ve9gra]

I'm talking out of my ... hat ... here but could this be caused by the calendar script also containing it's own distribution of ionCube? Version conflicts?

[Brian]

This is a sign of sessions not working or configured correctly. Can you check that the sessions directory [according to phpinfo()] exists and has write permissions?

[kryptronic]

Thanks for the pointer.

Our php.ini file pointed to /var/lib/php/session which under RedHat is installed by the PHP RPM with ownership as apache.apache. No other PHP scripts on the server used that dir by default (they all referenced their own). Changing ownership to nobody.nobody got the admin section working, however the solution was not optimal as I don't want just anyone installing a PHP script and writing out sessions to /var/lib/php/session.

Therefore, I decided to modify /calendar/setup/sessionPath.php and include the following code:

<?php

$sessionPath_filename = dirname(__FILE__);
$sessionPath_filename = str_replace('setup/sessionPath.php','session',$sessionPath_filename);
session_save_path($sessionPath_filename);

?>

After doing this, I created the directory /calendar/session, chmoded to 777 and put a .htaccess file in there with these contents:

AuthUserFile /none/
AuthGroupFile /none/
AuthName ByPassword
AuthType Basic
<Limit GET>
require valid-user
</Limit>

So session information couldn't be pulled up via a simple web request by anyone.

It would have helped out a good bit if instructions existed somewhere that gave an indication that the admin login looping could have been either (1) permission related, (2) ownership related or (3) session save path related. For (3) a pointer to /calendar/setup/sessionPath.php would have been great.

If you were to include this hack in your standard distro, it could help avoid the issue where the session save path is not writable by the web user (which I think is a pretty regular scenario).

Anyway, thanks - we've got it working.

[Brian]

Glad you got it going!

ve9gra and I both missed the problem as described by brandon in the first post. I didn't pick up on the actual issue at hand until your post.

This sessions path issue is covered in the instructions under the Help/Installation section:

http://docs.easyphpcalendar.com/Help/Installation.htm