Uploaded image for project: 'phpBB3'
  1. phpBB3
  2. PHPBB3-6915

New registration form loops back to Agreement

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Resolution: Fixed
    • 3.0.0
    • 3.0.1
    • None
    • PHP Environment: 5.2.1
      Database: MySQL 5.0.27

    Description

      This was originally entered as a topic at http://www.phpbb.com/community/viewtopic.php?f=46&t=711655

      I did a fresh install of phpBB3 on Windows 2000 server using Apache 2.2 server and PHP 5.1.3. I made all the desired changes to a new style based on prosilver and had everything running just fine.

      I then did a fresh install on Linux under Apache 1.3 with MySql 5.0.27 and PHP 5.2.1. I installed the new style I had created, set up the categories and forums. I then registered three users at first and everything worked as expected (that is, after entering the visual confirmation and clicking Submit in the Registration page, the user was successfully registered). I then made the forums live and went to bed. Several people registered successfully and then things started to go wrong.

      The registration process appears to be broken. The user clicks the Register link and sees the Agreement. Clicking Accept moves to the Registration page. Filling in the Registration form and clicking Submit is where it goes wrong: the user is redirected back to the Agreement page.

      I inserted some debugging statements in check_form_key() function in functions.php. The statements show that the comparison between $token and $key is failing.

      This function is called when the Submit button is clicked on the Registration page (and on a number of other forms as well). The form name is "ucp_register", the timespan is -1 (set in the Admin console), the return page is an empty string, trigger is false, and minimum time is 0 (set in the Admin console).

      (In other words, the time span and minimum time have both been disabled in the Admin console).

      As part of my investigation, I determined that when check_form_key() is called for the ucp_register_terms page, it has a specific user_form_salt value. When check_form_key() is called for the ucp_register page, it should have the same user_form_salt value. I have verified this is the case for successful registrations. For those situations where clicking the Submit button bounces the user right back to the Agreement page, the user_form_salt value was different for the two pages.

      I used logging to track the user_form_salt value when it is created in a new session and I noticed that the user_form_salt value changes apparently globally whenever a new session starts. That is, I see one user_form_salt value when check_form_key() is called for the ucp_register_terms page, I then see a new session created by someone else before I submit the registration page. The user_form_salt value used for the ucp_register page matches the new session user_form_salt value and that is different from the user_form_salt value used on the ucp_register_terms page. Somehow, the user_form_salt value for my session changed between the two pages as a result of a new session being created by someone else.

      I would expect the user_form_salt value to be confined to a specific session assigned to a unique user. I think that is what the code is doing but I can't be sure.

      Please note that I'm running on Apache 1.3. Is there a possibility that session values are getting mixed between sessions because of Apache? Or is there a way in the phpBB3 code that would allow the user_form_salt value to be changed so that it affects all sessions?

      I have created a work-around that works for me. It isn't pretty but it works.

      I force a constant form salt code during the registration process and the hack works. I don't like it and I'm sure it raises all sorts of questions but I have heard no other answers at this point.

      To me, this confirms that there is some sort of interference with the user_form_salt value and other sessions but I don't know the root cause. There is no problem with the user_form_salt code when posting or sending private messages, only during the registration process.

      Here is what I did (the hack is clearly marked):

      class ucp_register
      {
      	var $u_action;
       
      	function main($id, $mode)
      	{
      		global $config, $db, $user, $auth, $template, $phpbb_root_path, $phpEx;
       
      		//
      		if ($config['require_activation'] == USER_ACTIVATION_DISABLE)
      		{
      			trigger_error('UCP_REGISTER_DISABLE');
      		}
       
      		include($phpbb_root_path . 'includes/functions_profile_fields.' . $phpEx);
       
      		$confirm_id		= request_var('confirm_id', '');
      		$coppa			= (isset($_REQUEST['coppa'])) ? ((!empty($_REQUEST['coppa'])) ? 1 : 0) : false;
      		$agreed			= (!empty($_POST['agreed'])) ? 1 : 0;
      		$submit			= (isset($_POST['submit'])) ? true : false;
      		$change_lang	= request_var('change_lang', '');
      		$user_lang		= request_var('lang', $user->lang_name);
       
                      //vvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvvv
       
      		// (slepisto): Hack to sync up register terms and register page to the
      		// same salt value; otherwise, any other session starting during the
      		// agreement phase will destroy the salt and block the registration
      		// process.
      		$user->data['user_form_salt'] = '9c11b95a5486d204';
       
                      //^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
       
      		$formtok = $_POST['form_token'];
      		$creation_time = abs(request_var('creation_time', 0));
      		// not so fast, buddy
      		if (($submit && !check_form_key('ucp_register', false, '', false, $config['min_time_reg']))
      			|| (!$submit && !check_form_key('ucp_register_terms', false, '', false, $config['min_time_terms'])))
      		{
      			$agreed = false;
      		}
       
                  rest of function...

      Attachments

        Activity

          People

            Kellanved Kellanved [X] (Inactive)
            slepisto slepisto
            Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: