FORUMS


The Form Tools forums are no longer active, but the old posts have been archived here. Please see the Help page on how to get help / report issues.

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Trouble logging in. (No user account ID was found in sessions)
#1
Question 
I just installed Form Tools 2.0 yesterday and got it working ok.

I'll start off by saying that I like this application very much. I already tried PHPMailer-FE Form Mailer and 2 others and I scrapped them all because they weren't user-friendly enough. Form Tools is easy to use with GREAT documentation.


Now, on to my problem:

I had to use the password md5 hash generator on your site and enter a new hash value into the database before I could log in to my administrator account.

Now, sometimes, when I try to log in to the admin account, I get this error message:

Quote:No user account ID was found in sessions. Please log in again below.

Sometimes I get it multiple times in a row with no successful logins (making sure the user/pass are correct), then out of the blue, the login will work. Then sometimes I will be clicking through the Form Tools interface and it will kick me back out with the same message and I have to log in again. Sometimes getting the error multiple times again, and sometimes it logs me in on the first try.

Any ideas on a way to fix this?
Reply
#2
Interesting... I sometimes get this error when I try logging in because I go to "mysite.com" instead of "www.mysite.com". PHP sessions need the subdomain to the be same otherwise it won't be able to store & access them properly. However, Form Tools *should* redirect after the first failed attempt to the correct subdomain. This wouldn't explain multiple attempts like yours.

Hmm. The inconsistency sounds rather like something's weird going on on your server. Let's try bypassing it altogether: add the following line to your /global/config.php file.

PHP Code:
$g_session_type "database"

That will tell Form Tools to use database sessions.

Let me know if this helps any.

- Ben
Reply
#3
Nope, that didn't work. In fact, it made it worse. When that line is in config.php, then I can't log in at all. I keep getting the same message over and over again. When I take it back out, then at least the login works some of the time. I tried it twice just to be sure and I didn't get a single successful login attempt when that line was present.

Even when I do login, sometimes it only lasts a couple clicks, then it kicks me out. For example, I logged it, it took me to the "Forms" page with a list of my forms, I then clicked "Modules" in the menu and it immediately kicked me back out to the login screen with the same message. Less than 20 seconds after I logged in.
Reply
#4
I'd also like to add that I do have other PHP apps installed on this server with logins such as Coppermine Photo Gallery and Pommo Mailing List software and they have no login issues, so I thought I would let you know in case that gives you any information.
Reply
#5
Hey Louie,

I'm not sure if those other apps use sessions or not; it sounds like that's the cause of your problems. It does sound rather like something funky is going on on your server... the inconsistent behavior just doesn't make sense. Form Tools need to keep track of various information about the user while they're logged in. If it can't, it'll just boot you out and show that message like you described.

I encountered a problem like this once before and it was due to some additional server-side restrictions in place that limited the amount of information that can be stored in sessions at one time. Could you check to see if you have suhosin installed? You can find it if you load up a page with this content:

Code:
<?php
phpinfo();
?>

That will list most pertinent information about your PHP environment.

Also: who's your hosting provider?

- Ben
Reply
#6
There is nothing about suhosin on my phpinfo page, so it must not be installed.

My hosting provider is Ipower.

I know that I have installed apps that use sessions on my site before because I had to enable sessions in my custom php.ini and make the sessions directory writable. And those apps always worked fine after I set that up.

I've coded a lot with PHP, but have not used sessions before because I've never had the need, so that's why I can't help you troubleshoot. Do you have any code I can run to test out the sessions capability of my server? That might give you some more info.
Reply
#7
Hey Louie,

No, I don't have any existing test code unfortunately.

Any chance you could send me your FTP info & Form Tools login info (ben.keen@gmail.com)? No worries if not, but I could do a little debugging to see what's going on. It's definitely session related, but I don't know what. My hunch is that perhaps too much info is being stored, but I'm really not 100%.

- Ben
Reply
#8
Thanks Ben for such an outstanding application.
We are running FT for some time now (latest 2.0.4) and everything was working fine.
Today we faced the same problem Louie described, without changing anything. We repaired the tables and changed the password (md5 encrypted) using the tool provided from Ben at:
http://docs.formtools.org/encrypt.php
but nothing changed, we couldn't login to the admin panel.

Finally, adding the
Quote:$g_session_type = "database";
to the config file did the trick.

Searching the forum i found some posts with related problems.

One question Ben, we would be more than interested in your opinion why suddenly the login breaks, after working for such a long time, as it was in our case?

Thanks again!
Reply
#9
Huh! Interesting.

I don't think it was an encryption thing - more likely a sessions issue. The fact that you couldn't log in either points to the username/password being incorrect or that the sessions no longer work. This isn't that uncommon: if the server config changes - like, someone changes permissions on the temporary sessions folder, or if the folder was changed to something invalid - it can give every appearance of a failed user account. But in fact, Form Tools just tried and failed to create a session file for the user logging in, and automatically booted them out.

If you wanted to get to the bottom of it, I'd check there. Good luck! Smile

- Ben

Reply
#10
The trouble has found here about the not properly logged in because the user account and ID was not get for this session of working class. The junior member has posted this query with the best and creative kind of the regards for easy essay solution of this problem as well.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)