Please see these posts: http://forums.aatraders.com/viewtopic.php?127403b5664c4b6371c23c4af2e52178abad1769e8c286cd and http://forums.aatraders.com/viewtopic.php?127403b5664c4b6371c23c4af2e521787cbc6f491c414803

Thses cover the information we need in order to help localize your problem. Also have you installed all the patches???

Well if that were the case then none of our gameservers would be working.

No, it does not have all the patches ...

We have been frantically working on a new version and didn't think we should release another version patched. However ya never know we may change our mind.

Do they have sessions enabled on this server? Its acting like its not finding any session data and dumping you back to a login. Can you link a phphinfo() somewhere? That might help to see that file.

Can you login to your admin.php and have you checked the admn log? Just want to see if there are any errors there. As the phpinfo looks fine from what I can see.

When you ran create_universe did you see any errors as it progressed, andy sql errors at all?

Also you might update adodb .... I didnt think you wou;ld need to, but I'm reaching for anything right now. You can get it here:
http://sourceforge.net/project/showfiles.php?group_id=42718

Make sure you install it in the same place in the backends folder as the current one.

Let me know if it works. PJ told me a few minutes ago hes going to put up a new release with all the patches and the new adodb in place. Not sure when today, but later this afternoon or early evening. So if that still doesnt work you can try the new patched version later today.

The download is up...

Now there is one change I didn't make to the patched download but you can make it on your end if you still have problems.

Load the config.php program located in the config directory.

Find:



and comment out those lines so it looks like



The session handlers are a hold out from way back when we forked from NGS. They are totally useless for a game like this and diverting the session handling causes more problems than you acn imagine. They never should have been included and we should have removed them. It was a bad design decision to use them or leave them in.

The main game that was running for over a year had those lines commented out and never a problem and there never would be a problem. I have found some sites get picky if you divert the session handler in PHP.

Glad that worked.

Like I said there are many hosting services that really don't like people moving the session handling from the default. So what happens is your login fails because the session data was never saved or retrieved.

Here is the thing, it serves absolutely no security service like it was intended. All the session handler the game does, in this instance, is move the session information from files stored in the tmp directory on the server to a database table and storing the serialized and encrypted data. A person would have to have root access to the server or have hacked the server to get to the information in the tmp directory where the session files are normally stored.

And if they have hacked the server to get to that information they can just as easily pull the data from the database session table and decrypt it on the server.

Even though the session data is stored in the database tables in an encrypted format it is NOT encrypted in the session variables used by PHP. So the only real security is in storing it on the hard drive and that information is usually deleted after about 5 minutes depending upon the PHP settings on the server.

One of the things we have corrected in the next version is we are not putting the players email and password in the session data. That was a stupid hold over from NGS that we should have corrected but never did. We work a much better way now by storing the player ID in the session data.

So using encrypted sessions is really giving someone a false sense of security because if they can get in to the normal php session files they can just as easily get into the encrypted session table and pull out unencrypted data. It just added extra overhead that was useless if you logically reasoned it out from a hackers point of view.

Now that I have overloaded you with information you could care less about I will get back to work.

That usually means the cron isn't running or isn't completing. Try running the scheduler outside of the cron and see if it fails.

I love to hear others opinions on this. I'll be the first to admit I don't know everything about sessions. You have brought up some interesting arguments. And made me realize a few things about some of the other software I have been programming.

First I want everyone to realize our initial login code came from forkings from other games. I had not looked at the login code till a short time ago. I about fell out of my chair when I saw passwords were being stored in the session data. UGH! This is changed in the new version.

We were not actually saying we were going to change back to storing sessions in the tmp folder. The user above was having problems with the encrypted sessions, so removing that session handler didnt change it to store sessions back in the unsafe TMP folder just stored the session in the database like the it was usually stored in the tmp folder.

Believe me ... if you run your own dedicated hosting and manage your own servers you will realize real fast the downfalls of the /tmp folder.

There are a number of things I'd like to see to improve security, but we need to walk before we run. This new version has presented many new challenges and changes. Any suggestions and information on this subject are welcome, while I can't guarantee we will use them or implement them, this has become a very interesting topic.

This is true anyone can access the directory but the files in that directory can only be accessed bu the users or groups that have been assigned to those files. Exactly the same way as any other file on the server. Just because the directory is shared doesn't mean that the files assume the directories attributes. That does not happen in the tmp directory for the session files.



Actually that is not true. If you have shared hosts on the same box then each host will have different user id for accessing the session data. Also, if a user is able to FTP in and access the session data for any of the shared hosts then the server is WIDE open to that user. Actually the server would have to be specifically configured to allow that to happen.



Actually Garbage Collection is running even on data stored in the temp directory by the default session handler. It is no different from using a database session handler. The data is expunged after a set period of time. Actually, it does not help with load management at all. There is far more overhead using a database managed session handler than the default one. The only ADVANTAGE for using a database managed session handler is to allow a user to access multiple sites on the server using the same session id. Otherwise a different session id would be created for each site.



Actually they do need root access or the same access that has been assigned to the files by the orginator of the files. Some hosts will not allow the session handler to be changed from what they allow. Kind of like how some companies will not allow the use of cron tasks for security reasons. They like to keep control over those things on their end.

I think everyone who has ever had a login loop problem with other forks of the game will find that it is usually caused by changing the session handler to use a database.



Actually, you do not need the session handler and the game never has needed it. It is unneeded overhead. If you think that most shared hosting servers are that vulnerable then they should be having massive problems with hackers and that would cause alot of news stories about it. If the built in session handler was as insecure as you are claiming then there would be massive security problems being reported all of the time on most news sites.

Also, if a person has FTP access that allows them to read the session files that are stored in the tmp directory then they can install a SIMPLE PHP program on the site that will pull out all session data from the database in decoded form. They would get a nice list of all the variables and the data that was stored in the database. Just install the program under an innocuous name in the web folder and call it on a regular bases to dump and unencrypt the stored session data.

Honestly, if you look at it from a HACKERS point of view storing the information in a database file in an encoded form is far less secure. Especially when using the ADOdb session handler as all the code that is needed to unencode the data and dump it is right there. A generic program can be created that could be installed on ANY server using ADOdb's session handler and dump the completely unencoded session data at any time.

BTW, I have to make one correction...

I was wrong, PHP Session files are not stored in the tmp directory. Apparently some really, really OLD versions of PHP did this in the past.

Sessions are stored in the /var/lib/php/session directory and makes it even harder for anyone to access.

You will also find that most shared hosts have their own session handler installed for PHP for load balancing purposes that is much faster and more efficient than using a PHP coded one. Usually those hosts do not allow PHP to create it's own session handler through something like ADOdb's session handler.

An excelent reading I might add! Nothing wrong with pointing out holes. I tell everyone everyday the only way to be 100% secure is to not be plugged into the net at all If someone says they are 100% secure, its time to worry.

Great discussion on sessions. Keep up the good info!