magento2: Cannot get customer session data

To all the people here suggesting to mark a block as non-cacheable: keep in mind that one non-cacheable block in a layout will make the entire layout non-cacheable (talking about full page cache here).

The consequence is that the page in question will never be cached by the FPC, and if your non-cacheable block happens to be in a page header/footer that you use on all your pages, then full-page caching will be completely broken for your entire website. That is a big performance price to pay.

I have tried like this and got the customer session object when the cache is enabled.

<?php

namespace Test\Stack\Model\Test;

use Magento\Framework\ObjectManagerInterface;

/**
 * @var \Magento\Framework\ObjectManagerInterface
 */
protected $_object;

class Test{

     public function __construct(ObjectManagerInterface $interface)
     {
        $this->_object = $interface;
     }

     public function getCustomerSession(){
        $customerSession = $this->_object->create('Magento\Customer\Model\SessionFactory')->create();
        return $customerSession;     
     }
}

I can confirm this bug, when I’m logged in fronted

When I use this :

$ObjectManager = \Magento\Framework\App\ObjectManager::getInstance();
$session =  $ObjectManager->get('Magento\Customer\Model\Session');
return $session->isLoggedIn();

My return is false…

But, when I used this, it’s work fine :

$ObjectManager= \Magento\Framework\App\ObjectManager::getInstance();
$context = $ObjectManager->get('Magento\Framework\App\Http\Context');
$isLoggedIn = $context->getValue(\Magento\Customer\Model\Context::CONTEXT_AUTH);
return $isLoggedIn;

@tehXor Thanks for the tip on flagging the layout as cachable=false.

That worked like a charm for me!

I noticed that having all types of cache except Full page cache getting data from session works normally. So I guess the problem is in Full page cache.

This is NOT a problem in full page cache. It is supposed to work this way saving all necessary data in HttpContext so that when you serving cached page there is even no need to start PHP session.

See http://devdocs.magento.com/guides/v2.2/extension-dev-guide/cache/page-caching/public-content.html#configure-page-variations for details.

@Nuranto, http://devdocs.magento.com/guides/v2.1/extension-dev-guide/cache/page-caching/private-content.html explains how to pass customer-specific data properly.

First of all I also would consider this a bug as it is really annoying and therefore should be fixed / handled better imho.

However I doubt the Mage Devs see it as bug as they always declare the code parts were they use \Magento\Customer\Model\Session themselves as not cacheable. So it looks like \Magento\Customer\Model\Session is not intended to work with cache. I’m not sure if it is true for all problems with \Magento\Customer\Model\Session but I guess it is for a lot of them.

We came across this problem in a custom block and could “fix” it easily be also declaring it as not cacheable in its layout config XML. So instead of <block class="OurCompany\OurExtension\Block\Name\Index" name="our-block-name" template="OurCompany_OurExtension::blocktemplate.phtml"/>
we needed <block class="OurCompany\OurExtension\Block\Name\Index" name="our-block-name" template="OurCompany_OurExtension::blocktemplate.phtml" cacheable="false"/>
in our XML. Maybe some other problems can be solved in a similar way.

@deepanshu27193 You cannot do this in an easy way, CONTEXT_GROUP and CONTEXT_AUTH are the only attributes provided by \Magento\Customer\Model\Context directly. There may be another way but it would probably be a little bit more complicated.

@korostii passing pieces of HTML via AJAX in 2k17, really? 😃

The $_isScopePrivate is flawed by design (one small mistake and your customer private data is cached for everyone). Too bad this M1-style FPC mechanism was not eliminated at all (just because it requires a lot of refactoring).

and cacheable=false. Not sure if that changed in 2.2.

Didn’t check 2.2 yet as well. For the 2.0 GA there was a separate effort to make all product/category/CMS pages not using the obsolete FPC mechanism. Some pages, like My Account, do not really suffer from being not cacheable.

Main problem is that developers still think in terms of generating some HTML thus getting an unexpected system behavior. I do agree that CustomerData mechanism could be a bit easier to use, hiding all unneeded implementation details under the hood.

@jstrez77 I’m not sure what exactly you’re trying to solve. What I described in my last comment is exactly what happened to me until I realized how much worse I made it. I’m now trying to fix it, and it seems that the solution is to load user-specific data through javascript instead of php, this way the server page can still be cached and the client will still see relevant info for their account.

First I though that would have to be AJAX, but actually Magento already loads a bunch of data that you can just access without further calls to the server. Look at the example at https://github.com/magento/magento2/blob/develop/app/code/Magento/Theme/view/frontend/templates/html/header.phtml

Also, what helped me a lot in understanding all this is: https://inviqa.com/blog/how-full-page-cache-works-magento-2

Also bug in Magento 2.1. I noticed that having all types of cache except Full page cache getting data from session works normally. So I guess the problem is in Full page cache.

I think it’s related issue: https://github.com/magento/magento2/issues/6392

I have installed Magento 2.1.1 latest version still facing this issue which is not able to retrieve customer data from session in product view page, when cache is enabled

Magento2 still has Zend framework 1 and prototype.js inside

ZF1 is in process of elimination and some reminants of prototype.jsonly left in Admin UI, it would be eliminated if needed just like it was done for storefront (a good one for 'up for grabs', by the way, last time I grepped there were like ~80 occurrences of it in require section of components).

if it’s not even done for the core yet?

It was done for crucial pages, sometimes regressions happened like review block on product page, some third-party developers may be unaware and accidentally make such pages uncacheable 😦 That’s why such ajaxified FPC need to be completely eliminated for good.