formtools / core

The Form Tools Core.
https://formtools.org
207 stars 78 forks source link

special character in form with $g_session_type = "database" leads to session termination #721

Open mabuch opened 4 years ago

mabuch commented 4 years ago

Hi

I have encountered a very strange bug. Luckily I was able to reproduce it quite easily. To reproduce the bug follow these steps:

  1. Install a fresh formtools instance of Version 3.0.20 (I wanted to check whether the problem is reproducible with a new clean installation, but it should also work with an already existing setup)
  2. Create a form (I created an Internal form with 5 fields (default settings))
  3. Add a submission (I did this directly as Admin in the backend), and add the character "č" to one of the fields.
  4. You can now list/view the submissions and also edit the submission, so far everything works fine.
  5. Now add $g_session_type = "database" to global/config.php, quite possibly you have to login again after this.
  6. If you view the submission now, and edit the submission containing the character "č", this seems to terminate the session. More specifically: As soon as I open the submission edit page (formtools/admin/forms/edit_submission.php?form_id=1&view_id=1&submission_id=1) the session seems to get terminated. No matter what I do (click update, navigate back to form list in the navigation, ...), I always get thrown to the login page with the "notify_no_account_id_in_sessions" error message.
  7. If I disable $g_session_type = "database", everything works fine again. On the other hand, if I delete the character "č" from the form, everything works fine as well. But with the combination of "č" and $g_session_type = "database" the session gets terminated whenever the submission edit form with this character gets opened. There might be other special characters that cause problems, I just so happened to stumble upon the problem with this character.

I will try to narrow down the problem in the code on the weekend, but it has been quite a while since I debugged php and I cannot promise anything.

btw: the collation of the fields in ft_form_1 is "utf8_general_ci", so everything is as it should be. I tested this with PHP 7.3 and 7.4

mabuch commented 4 years ago

I made some progress tracking down a probable position where the error might occur.

I have noticed that the contents of the submission get added to the session (in the database table ft_sessions). However, here the special character is not properly stored, instead a "?" is saved (see field1; [with a string length of 2]): [...]s:26:"last_edit_submission_state";a:4:{s:13:"submission_id";s:1:"1";s:7:"view_id";s:1:"1";s:10:"tab_number";i:1;s:4:"data";a:5:{s:6:"field1";s:2:"?";s:6:"field2";s:1:"1";s:6:"field3";s:1:"3";s:6:"field4";s:5:"sgsdf";s:6:"field5";s:3:"fgj";}}[..]

This data gets added to the session by function-call Submissions::trackCurrentEditSubmissionFields($grouped_fields, $submission_id, $view_id, $tab_number);in line 81 of edit_submission.php It is then saved to $_SESSION, where the special character is still correctly stored as "č".

This is as far as I got today. With $g_session_type = "database" it seems that special characters are not written correctly into ft_sessions. I still have not tracked down where exactly this error occurs (where $_SESSION gets written into the database), neither do I know how this leads to the invalidation/termination of the session.