Cache issues: user sees other's data

[ghost]

We are experiencing grave cache issues with this module. After having logged in using oneall (FB, g+, etc ..) the user is allowed to go in but he access other user's account !!!

I.e.

• login as FooUser
  • username: Foo
  • address: FooAddr
  • ...
• login as BarUser
  • username: Foo
  • address: FooAddr
  • ...

As far as i can see it looks like some caching issue on the user token ..

any idea about the root reason? I'm ready to debug and fix, but need some directions ..

Thank you in advance

[SchlesserClaude]

Hello, the plugin uses two tables to map social network profiles to user accounts:

_DB_PREFIX_  + oasl_user
_DB_PREFIX_  + oasl_identity

Could you it be that you have reset your users without resetting the mapping tables?

[SchlesserClaude]

If it's a caching problem, then it could be that the cache displays old pages from the cache. So when user FooUser logs in, the cache might displayed a page which was cached for BarUser.

[ghost]

@SchlesserClaude of course what happens is what you say .. the point is that disabling oneall plugin no caching issue appears for users .. I think that if it would be a page cache issue it should occur with or without oneall plugin

BTW, no user reset was made .. I think it could be a wrong cache key in some template you use (smarty cache I mean) ... could it be?

[SchlesserClaude]

Could you give me the link to you shop so that I can test the error?

[ghost]

Sorry, but we can't keep it online as every private user data will be disclosed ..

Will try to debug next days

[ghost]

Hi,
Not sure I understand the scenario you describe in the first post.
Are the usernames the same?
Is BarUser a regular, existing, user, or was the account created with social login?
Also, could it be that the account was automatically linked because of matching email addresses?

Thanks.

[ghost]

@frdpnl

Accounts seems to be created with social login .. I'll try to reproduce to a test server ASAP in order to give you better statistics

User foo registers and logins using sl
User bar do the same, but after being redirected from FB back to the shop he sees foo data in his account

[ghost]

Ok, thanks.
As mentioned, one possibility is that the email addresses match, and both accounts are linked.

[ghost]

@frdpnl this is not the case ..

[ghost]

Hi,
Ran a few tests with cache options on, and couldn't reproduce the problem you describe. For Prestashop 1.6.x versions.
If you have some other info on the setup, or steps involved, that would help troubleshoot further.
Thanks.

[ghost]

I can't find a reason too ...

Have you OPcache enabled too? I'm trying to assure it is not the problem ...

This is my opcache configuration, can you try it?

[ghost]

@frdpnl did you tried this OPcache settings? .. It seems that they are giving some strange behavior on my server .. if you can reproduce I'll work hard to isolate the bad setting.

Thanks

[ghost]

Hi,
I've tried to set the same Opcache settings, but could not reproduce the behaviour.
However, I do not use php 7 (but 5.5), and have not set any blacklisted file either.
Is there anything specific with the 2 profiles involved, as far as you can see?
Or does this occur for any 2 profiles?
If you have a public URL, I can test with some of my test accounts.

Thanks.

[ghost]

Could be caching issue with ajax requests? ...

I'm seeing a number of PS files not sending cache-invalidation headers on Ajax responses ... I have caching issue with BO orders/new-clients/new-messages badges too ..
Badges issues seems to be solved adding no-caching headers to the response ..

Hope this can help

[ghost]

I'm going on fighting against this issue ..

• added CURL option to have a fresh connection -> no luck

Im' doing some tests .. it seems to be a problem with FB .. but I can't understand why

CLeared browser cache, removed cookies, emtied any king of server cache ,.. server reboot done ..

Unfortunately I can't leave the module active on the server for your tests, as it is a grave security hole and users personale data disclosure ..

Can you point me to some kind of debugging I can perform by myself? What is the data flow I have to follow to try to find the bug?

This is my settings:

[ghost]

Just dropped everything in the DB:

• DROP every oneall DB record
• added curl_setopt ($curl, CURLOPT_FRESH_CONNECT, 1); in tools.php

AFAICS it seems to work !!!

[SchlesserClaude]

Hello,

if this solves the issue then the problem is related to the mapping tables:

DB_PREFIX + oasl_user
DB_PREFIX + oasl_identity

Maybe at seem points you removed users but the mapping table was not updated

[ghost]

If I login via social with a new user, for test, and then I remove this user in PS BO, then the related records in these mapping tables are not automatically removed.
Is this the intended behaviour?

Moreover.. in a such scenario, how the hanging records can explain the resulting behaviour?

Thanks