Project

General

Profile

Actions

Bug #82490

closed

FE session broken after it has been lost

Added by Franz Holzinger almost 7 years ago. Updated over 5 years ago.

Status:
Closed
Priority:
Must have
Assignee:
Category:
System/Bootstrap/Configuration
Target version:
Start date:
2017-09-15
Due date:
% Done:

100%

Estimated time:
TYPO3 Version:
8
PHP Version:
7.0
Tags:
Complexity:
Is Regression:
Sprint Focus:

Description

The FE session cannot be restored after it has been lost because a change of the IP address. This did work with all TYPO3 versions before TYPO3 8.7.

Use case:

A user has put items into the basket. Then the IP changes. This leads to a lost FE session. All the items in the basket are gone. This is fine so far. However now the user realises that he has to restart with putting items into the basket. Now the FE session is completely broken. Every item in the basket is immediately gone with each reload of the page. It is not possible any more to put any item into the basket. The storing of the FE session does not work any more.
It only helps to clear the FE TYPO3 Cookie in the browser (Firefox). Then everything works fine again.

Actions #1

Updated by Benni Mack over 6 years ago

  • Status changed from New to Needs Feedback

Hey Franz,

you should be able to use the lockIP option in TYPO3_CONF_VARS[FE] to disable the IP switch, right?

Actions #2

Updated by Franz Holzinger over 6 years ago

Hello Benjamin,

I use this Install Tool setting

[FE][lockIP] = 2

Integer (0-4). If >0, fe_users are locked to (a part of) their REMOTE_ADDR IP for their session. Enhances security but may throw off users that may change IP during their session (in which case you can lower it to 2 or 3). The integer indicates how many parts of the IP address to include in the check. Reducing to 1-3 means that only first, second or third part of the IP address is used. 4 is the FULL IP address and recommended. 0 (zero) disables checking of course.

But if the IP address changes then it is ok, that the basket is now empty and a FE user logged out. The problem is, that the feature to put a product into the basket is broken, if the IP address did change. I will never be again possible to buy a product unless the user clears his cookie.

Actions #3

Updated by Markus Klein over 6 years ago

  • Category set to System/Bootstrap/Configuration
  • Status changed from Needs Feedback to New
  • Assignee set to Markus Klein
Actions #4

Updated by Markus Klein over 6 years ago

  • Status changed from New to Needs Feedback

I made a little test extension, but I fail to reproduce the error.

Can you point me to the code in your ext that fails?

Actions #5

Updated by Franz Holzinger over 6 years ago

The session reading does not work after the IP change.

$tmpBasketExt = $TSFE->fe_user->getKey('ses','basketExt');

...

if ($bStoreBasket)  {
    if (is_array($this->basketExt) && count($this->basketExt))  {
        $TSFE->fe_user->setKey('ses','basketExt',$this->basketExt);
    } else {
        $TSFE->fe_user->setKey('ses','basketExt',array());
    }
    $TSFE->fe_user->storeSessionData(); // The basket shall not get lost when coming back from external scripts
}

The storing of the session data only works for the current run of the PHP script. But at the next execution of the php script, the getKey function reads an empty value and not the formerly stored array.

The full extension is here:

https://github.com/franzholz/tt_products/blob/master/model/class.tx_ttproducts_basket.php

Actions #6

Updated by Markus Klein over 6 years ago

I tested with

        /** @var TypoScriptFrontendController $tsfe */
        $tsfe = $GLOBALS['TSFE'];
        $session = $tsfe->fe_user->getSessionData('dummy_date');
        $tsfe->fe_user->setSessionData('dummy_date', date('c'));

        return $session;

I simulated the IP change by adjusting \TYPO3\CMS\Core\Authentication\AbstractUserAuthentication::ipLockClause_remoteIPNumber to report different IPs.

Actions #7

Updated by Franz Holzinger over 6 years ago

I have inserted your script inside of tt_products/model/class.tx_ttproducts_basket.php.

This PHP code is run twice in my case (one shop plugin and one minibasket on the same page). During the first run $session is always empty. At the second time it gives the correct date value. I can repeat this wrong behaviour several times by a page reload. The behaviour remains wrong until I will remove the FE TYPO3 fe_typo_user cookie. Then everything will be fine again and the $session is filled until the IP changes again. The session features is broken as soon as the IP changes for one time. It only still works during the run of one PHP script.

I did always change the IP address by making a new connection with the router.

Actions #8

Updated by Markus Klein over 6 years ago

what is your FE|lockIP value?

Actions #9

Updated by Franz Holzinger over 6 years ago

[FE][lockIP] = 2

Actions #10

Updated by Markus Klein over 6 years ago

This is really strange then, because it means that changing your IP should not invalidate the session at all. Your router will most likely deliver IPs within the C subnet so with lockIP=2 any address will be accepted.
Can you please debug what \TYPO3\CMS\Core\Authentication\AbstractUserAuthentication::ipLockClause_remoteIPNumber returns whenever it is called?

Actions #11

Updated by Franz Holzinger over 6 years ago

AbstractUserAuthentication.php (typo3_src-8.7.6):

protected function ipLockClause_remoteIPNumber($parts)
{
debug ($parts, 'ipLockClause_remoteIPNumber Pos 1 $parts');
    $IP = GeneralUtility::getIndpEnv('REMOTE_ADDR');
    if ($parts >= 4) {
debug ($IP, 'return 1 $IP');
        return $IP;
    }
    $parts = MathUtility::forceIntegerInRange($parts, 1, 3);
    $IPparts = explode('.', $IP);
debug ($IPparts, '$IPparts Pos 1');
    for ($a = 4; $a > $parts; $a--) {
        unset($IPparts[$a - 1]);
    }
debug ($IPparts, '$IPparts Pos 2');
debug (implode('.', $IPparts), 'return 2');
    return implode('.', $IPparts);
}

1.) I have 89.1.172.148 :

FrontendUserAuthentication.php  171 start
AbstractUserAuthentication.php  443 checkAuthentication
AbstractUserAuthentication.php  611 fetchUserSession
AbstractUserAuthentication.php  971 ipLockClause_remoteIPNumber
AbstractUserAuthentication.php  1178    debug

Integer
2
ipLockClause_remoteIPNumber Pos 1 $parts

FrontendUserAuthentication.php  171 start
AbstractUserAuthentication.php  443 checkAuthentication
AbstractUserAuthentication.php  611 fetchUserSession
AbstractUserAuthentication.php  971 ipLockClause_remoteIPNumber
AbstractUserAuthentication.php  1186    debug

Array
0   89
1   1
2   172
3   148
$IPparts Pos 1

FrontendUserAuthentication.php  171 start
AbstractUserAuthentication.php  443 checkAuthentication
AbstractUserAuthentication.php  611 fetchUserSession
AbstractUserAuthentication.php  971 ipLockClause_remoteIPNumber
AbstractUserAuthentication.php  1190    debug

Array
0   89
1   1
$IPparts Pos 2

FrontendUserAuthentication.php  171 start
AbstractUserAuthentication.php  443 checkAuthentication
AbstractUserAuthentication.php  611 fetchUserSession
AbstractUserAuthentication.php  971 ipLockClause_remoteIPNumber
AbstractUserAuthentication.php  1191    debug

89.1

return 2

Everything works with sessions.

2.) I have a new IP 78.34.189.115 :

FrontendUserAuthentication.php  171 start
AbstractUserAuthentication.php  443 checkAuthentication
AbstractUserAuthentication.php  611 fetchUserSession
AbstractUserAuthentication.php  971 ipLockClause_remoteIPNumber
AbstractUserAuthentication.php  1178    debug

Integer
2
ipLockClause_remoteIPNumber Pos 1 $parts

FrontendUserAuthentication.php  171 start
AbstractUserAuthentication.php  443 checkAuthentication
AbstractUserAuthentication.php  611 fetchUserSession
AbstractUserAuthentication.php  971 ipLockClause_remoteIPNumber
AbstractUserAuthentication.php  1186    debug

Array
0   78
1   34
2   189
3   115
$IPparts Pos 1

FrontendUserAuthentication.php  171 start
AbstractUserAuthentication.php  443 checkAuthentication
AbstractUserAuthentication.php  611 fetchUserSession
AbstractUserAuthentication.php  971 ipLockClause_remoteIPNumber
AbstractUserAuthentication.php  1190    debug

Array
0   78
1   34
$IPparts Pos 2

FrontendUserAuthentication.php  171 start
AbstractUserAuthentication.php  443 checkAuthentication
AbstractUserAuthentication.php  611 fetchUserSession
AbstractUserAuthentication.php  971 ipLockClause_remoteIPNumber
AbstractUserAuthentication.php  1191    debug

78.34

return 2

TypoScriptFrontendController.php    1163    start
AbstractUserAuthentication.php  443 checkAuthentication
AbstractUserAuthentication.php  611 fetchUserSession
AbstractUserAuthentication.php  971 ipLockClause_remoteIPNumber
AbstractUserAuthentication.php  1178    debug

Integer
4
ipLockClause_remoteIPNumber Pos 1 $parts

TypoScriptFrontendController.php    1163    start
AbstractUserAuthentication.php  443 checkAuthentication
AbstractUserAuthentication.php  611 fetchUserSession
AbstractUserAuthentication.php  971 ipLockClause_remoteIPNumber
AbstractUserAuthentication.php  1181    debug

78.34.189.115

return 1 $IP

ContentObjectRenderer.php   6252    call_user_func_array
class.tx_ttproducts_pi1.php 64  main
class.tx_ttproducts_pi1_base.php    68  run
class.tx_ttproducts_main.php    451 init
class.tx_ttproducts_basket.php  113 debug

$session +++

Session is completely broken until I shall remove the FE TYPO3 cookie.

Actions #12

Updated by Markus Klein over 6 years ago

  • Status changed from Needs Feedback to New

Okay the issue has to do with a BE user being logged in at the same time. Reading the output above your BE|lockIP = 4.

So we need to check whether the invalidation of your BE login also kills the FE session.

Actions #13

Updated by Markus Klein over 6 years ago

  • Status changed from New to In Progress
  • Target version set to next-patchlevel

Can reproduce now.

Actions #14

Updated by Gerrit Code Review over 6 years ago

  • Status changed from In Progress to Under Review

Patch set 1 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/54347

Actions #15

Updated by Gerrit Code Review over 6 years ago

Patch set 2 for branch master of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/54347

Actions #16

Updated by Gerrit Code Review over 6 years ago

Patch set 1 for branch TYPO3_8-7 of project Packages/TYPO3.CMS has been pushed to the review server.
It is available at https://review.typo3.org/54353

Actions #17

Updated by Markus Klein over 6 years ago

  • Status changed from Under Review to Resolved
  • % Done changed from 0 to 100
Actions #18

Updated by Benni Mack over 5 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF