Project

General

Profile

Actions

Bug #54445

closed

Session data can't be fetched for non authenticated fe_users

Added by Marcin Sągol over 10 years ago. Updated over 10 years ago.

Status:
Rejected
Priority:
Must have
Assignee:
-
Category:
Frontend
Target version:
Start date:
2013-12-16
Due date:
% Done:

0%

Estimated time:
TYPO3 Version:
6.2
PHP Version:
5.4
Tags:
Complexity:
Is Regression:
No
Sprint Focus:

Description

Hi again,
as i need to store some data in session (basket items) for users visiting website i have created a little service to handle session action. All seems to work just fine for authenticated fe_user. The problems start with guests that are not authenticated.

Their data lands in 'fe_session_data' table identified by unique hash and this hash is a problem here. On each page reload its different - the $id (that is hash in fe_session_data table) changes in TYPO3\CMS\Frontend\Authentication\FrontendUserAuthentication - so the saved data is never fetched.

On line 406 we have:
// If new session or client tries to fix session...
if (!$id || !$this->isExistingSessionRecord($id)) {
// New random session-$id is made
$id = $this->createSessionId();
// New session
$this->newSessionID = TRUE;
}

and the $this->isExistingSessionRecord($id) always returns false for not authenticated user as it checks for session in 'fe_sessions' table where records are created only for authenticated users (method createUserSession() is calle donly for authenticated user)!

So all this results with this:
if we set some data to be stored in 'fe_session_data' (not authentictated user) it is put there on each reload as it cant find it because hash ($id) changes each time!

I hope this can be fixed and i did not missed something to make session works for not authentictated users.

Actions #1

Updated by Markus Klein over 10 years ago

  • Status changed from New to Needs Feedback

Hi!

I didn't test this on 6.2 yet, but session handling for non-authenticated users works fine in 4.7 at least.
How do you access the session data?

You should use the session API
$GLOBALS['TSFE']->fe_user->setAndSaveSessionData($key, $data);

Actions #2

Updated by Marcin Sągol over 10 years ago

Hi Markus,

@public function set($key, $value) {
$this->getFrontendUser()->setKey('ses', $this->prefixKey.$key, $value);
$this->getFrontendUser()->storeSessionData();
}@

this is my function to store data. $this->getFrontendUser() just returns $GLOBALS['TSFE']->fe_user; From what i see setAndSaveSessionData() is just a shortcut for this 2 actions. This doesn't work for me - there is always new id/hash generted as $this->isExistingSessionRecord($id) in mentioned condition will always return false; For test i removed this from IF statement and than my session data is fetched as it should.

Actions #3

Updated by Markus Klein over 10 years ago

  • Status changed from Needs Feedback to Accepted

Ok, then we've to find out what is different to 4.7.
Please also check if 6.0 and 6.1 are affected too.

Actions #4

Updated by Marcin Sągol over 10 years ago

I do not know how exactly the session handling works here (would have to investigate whole code) but what i want to know now is does the entry should be created in fe_sessions table not only for existing and logged in user but also for simple visitors?

Actions #5

Updated by Thorsten Kahler over 10 years ago

Marcin Sągol wrote:

I do not know how exactly the session handling works here (would have to investigate whole code) but what i want to know now is does the entry should be created in fe_sessions table not only for existing and logged in user but also for simple visitors?

fe_sessions is only used for login of FE user, not for storage of the session data (in contrast to BE); all session data of FE users, regardless of login or anonymous session, is stored in fe_session_data

Actions #6

Updated by Marcin Sągol over 10 years ago

Thorsten ok thank you for the explanation. My question is why then isExistingSessionRecord() checks fe_session and based on that is generated session id/hash for simple visitor? Or am im getting it wrong?

Actions #7

Updated by Thorsten Kahler over 10 years ago

Method isExistingSessionRecord() is overwritten in \TYPO3\CMS\Frontend\Authentication\FrontendUserAuthentication: if the parent method doesn't return a result from fe_sessions, fe_session_data is checked.

Actions #8

Updated by Marcin Sągol over 10 years ago

From what i see fe_typo_user cookie is not set after i cleard all of them to do more test. Is it required for proper session data handling ?

Actions #9

Updated by Thorsten Kahler over 10 years ago

  • Status changed from Accepted to Needs Feedback

Marcin Sągol wrote:

From what i see fe_typo_user cookie is not set [...]. Is it required for proper session data handling ?

Yes, the cookie is required for session handling.

Actions #10

Updated by Marcin Sągol over 10 years ago

Any ideas why it can;t be set? If i login with some fe_user account the cookie is created but not for guests.

Actions #11

Updated by Oliver Hader over 10 years ago

If the website is behind an HTTP proxy, Varnish or something similar - then this might be the reason for the fe_typo_user cookie not being forwarded and set at the client browser.

Actions #12

Updated by Marcin Sągol over 10 years ago

Thanks Oliver for the good suggestion. The problem was behind Varnish configuration. After small modifications all seems to work. Sorry for taking your time and thanks again all of you.

This issue can be closed.

Actions #13

Updated by Thorsten Kahler over 10 years ago

  • Status changed from Needs Feedback to Rejected

Issue closed on author request.

Actions #14

Updated by Markus Klein over 10 years ago

@Thorsten Kahler: Why are you setting this to rejected?? Did we reject something?
I guess we can "close" this issue.

Actions #15

Updated by Marcin Sągol over 10 years ago

Small info: when i was changing default Varnish configuration to work with TYPO3, i commmented this part:

sub vcl_fetch {
     if (beresp.ttl <= 0s ||
         beresp.http.Set-Cookie ||
         beresp.http.Vary == "*") {
                /*
                 * Mark as "Hit-For-Pass" for the next 2 minutes
                 */
                set beresp.ttl = 120 s;
                return (hit_for_pass);
     }
     return (deliver);
}

With this configuration back all works fine.

Actions #16

Updated by Thorsten Kahler over 10 years ago

Markus Klein wrote:

@Thorsten Kahler: Why are you setting this to rejected?? Did we reject something?
I guess we can "close" this issue.

IMHO it's easier to distinguish solved issues (which had an impact on the code base) from those that were sorted out by discussion. The request to change the code has been rejected by the author himself.

Actions

Also available in: Atom PDF