I had a form working, but after making some changes it no longer posts.
Instead at the top it says...
Your session has expired. Please log in again.
And then below that it says...
There is no form with this name or may be the form is unpublished, Please check the form and the url and the form management
One odd thing I noticed was that the link for the form is like this...
/index.php?option=com_chronocontact&Itemid=54
But when it posts (and shows the error) the url appears as...
/index.php?option=com_chronocontact&Itemid=54
(notice the & instead of &)
Does that mean anything? Any ideas?
Thanks
Hi xtempore,
As a security precaution Joomla forms use a 'security token' which is stored in the user 'session'. This is to check that the same person who opened the form is submitting it. The default session length in Joomla is 15 minutes; if your session expires then the token is no longer available and you get this message.
Usually it's not a problem . . . if it is then you can set the session length longer in your site Global Configuration; or comment out the toekn checking code ( there are instructions here in the forum).
Bob
PS The & and & aren't a problem - & is the correct way of showing a URL inside Joomla code.
I turned on debug and tried looking at some of the SQL that was running. One thing that looked odd to me was this query...
SELECT *
FROM `jos_chrono_contact`
WHERE `name` = ''
I looked in jos_chrono_contact, and there are 2 forms there (as I expect) and both have valid names, so I think that something is causing the above query to not be able to find the form.
I'll investigate further, but if anyone knows why this would be please let me know!
Okay - the SQL thing was a red herring. Just a side effect of something else not working.
It appears that the problem relates to the anti spam image verification. If I turn this off the form works!
But I want the anti spam! So I guess the next question is, how do I fix that?
I think I saw some other posts about that so I'll check them out.
Aha! I found what may be a CLUE...
I started delving into the Joomla code to see what might cause this error message.
The session object has a property called session.counter. The value SHOULD increment each time you view a new page.
If session.counter=1 then you may get the dreaded "Your session has expired. Please log in again."
This is stored as part of the data field in the jos_session table.
NORMALLY it is just serialised data, that is reasonably readable...
"__default|a:5:{s:15:"session.counter";i:1;..."
And if I just move from one page to another in Joomla then I can see the session.counter increasing each time (as expected).
BUT if I go to a ChronoForms form (complete with image validation), something weird happens.
Instead of my nice readable serialised data I get what looks like some sort of encrypted data...
"FGLfaWAjVnxYnDM_BJjmqhmwzNm0WO1aDigVE3DCXytLrrXdCaNVZNPCHID9gaG..."
My guess is that as soon as I post my form, Joomla tries to read this back in, and can't. As a result session.counter will be 0, then incremented to 1, and because it is =1 the error occurs.
So that's WHY it's happening. Now I just need some ideas as to how to STOP it!!!
Hi xtempore,
First off there is a session opened for each user - not just for logged in users. And that long string of characters is - I think - the form security token.
But, late at night I read your comment on &s backwards - it should *not* be appearing in a page url in your browser and I'm pretty certain that you are correct that it is causing at least part of he problem.
The urls that are being displayed are menu urls not standard Joomla urls which suggests that you have some form os SEF url -re-writing? I've looked through the RC4.11 code and I can only see one place where CF adds that suffix and it is to a full url like index.php?option=com_chronocontact&task=send&chronoformname=form_name. But it's is now early morning so I may have missed something again.
Bob
Hi Bob
Thanks for your continued assistance.
I think the whole url thing is just a side-effect of another problem. The main issue seems to be to do with the session data getting confused somehow, and after that occurs the ChronoForm goes astray. Maybe that part is something that needs to be fixed in the long term, but for now if I can just work out this session issue I'll be happy.
I'm still trying to get my head around the way the data field gets built and stored in the jos_session table.
As I already mentioned, whenever I am on a normal page the data field looks like ordinary serialized data. In fact if there is no image validation then the data field also looks like ordinary serialized data.
BUT when there is the image validation then the data changes to some encoded form (not sure of the encoding).
Another clue is that although there is an update to the session table showing in the debug SQL on the page, it is for normal serialized data, and I also noticed that the time field is different by 1 over what was shown in the SQL.
I think that what this means is that the form is triggering a normal update of the session, but that the image verification must be making an HTTP call that also triggers an update to the session record, and changes the format of data being used.
One more clue is that the administrator session always shows an encoded data field.
My next step will be to turn user login back on, create a user and see if they have a problem or not.
I hope that makes some kind of sense.
Okay. So having a logged in user didn't help. Results were the same.
But I was able to confirm that the image verification is indeed causing an update to the session.
To get the image it calls...
/components/com_chronocontact/chrono_verification.php?imtype=1
And this updates the session, in order to pass back the MD5 check of the random string for validation.
Still chipping away at this. I think if I could understand how Joomla saves session data, I might be able to crack it.
As mentioned previously the "data" field sometimes looks like serialized data, and sometimes like some weird encoded string.
I tried an experiment whereby I moved the chrono_verification.php (and default.ttf) to the root directory and called them from there. The result was that it showed a readable serialized string in the "data" field.
So, what seems to be happening is this. If you call a php file in the root directory, the data is serialized. If you call it in a subdirectory, the data is encoded.
So I think what is breaking the form is that index.php writes serialized data, then chrono_verification.php writes encoded data, and when index.php tried to process the form post it is expecting serialized data, but doesn't get it. The result is an empty session which it views as expired.
Hi xtempore,
You may be seeing different things here. The image verification file loads an MD5 encoded copy of the anti-spam string into the session so that it's available for testing on form submission.
Bob
I FINALLY managed to figure it out, and thought I should post here in case someone else suffers from the same set of symptoms.
It was all to do with the "php.ini"
The site where I was hosting the Joomla install allows me to override PHP settings by putting a "php.ini" file in the root directory. I thought that was all I needed to do, BUT IT WASN'T.
My host uses phpSuExec, so you can override PHP settings in this way, but if any scripts are running from subdirectories (such as administrator or components/com_chronocontact) they DO NOT pick up that "php.ini" file and instead use the default settings.
So how did that mess things up?
The main thing that got messed up related to sessions. You see when the ChonoForm used image validation it makes a call to "components/com_chronocontact/chrono_verification.php".
The problem is that that calls the standard Joomla session routines, and because of the differences in the php configurations it was writing session data in a DIFFERENT way to Joomla's main "index.php".
The next time "index.php" ran (on form post) it could not read the session data, and responded with a "session expired" message.
So how do you make it work under phpSuExec?
There's a couple of options, but I'll explain the one I used.
In the root directory of your Joomla install you need to put a line into the ".htaccess" file, that tells PHP where to find the "php.ini" file to use for ALL scripts on your domain regardless of whether they are in subdirectories or not.
It'll look something like this...
SetEnv PHPRC /home/<username>/public_html
Where <username> is your hosting user name. This may be different for your host so if you have problems check with them.
And of course you do need your "php.ini" file in the directory listed.
I hope this helps someone avoid the hours it took me to resolve this.
