Hello, we have some unexpected behaviour we cannot follow for now. For some reason we sometimes have

UKTSRTD5M

Hello, we have some unexpected behaviour we cannot follow for now. For some reason we sometimes have sessions with customer data but without UsernamePasswordToken (and therefore no ROLE_USER). The customers are stuck and are always redirected to the login redirect. Has anyone seen this before or any idea how this may come?

Unknown

How is your session redis built?

Andriy Netseplyayev

can that be that these are “old” sessions that were created before you’ve introduced UsernamePasswordToken into them?

UKTSRTD5M

From my understanding customer data is only introduced on login, where also the token is included. The state seems to arrive while using the shop, not at login time. So somehow the session needs to get replaced or altered - and for now i got no clue what causes it...

UKHD8KTMF

customer is refreshed in session data

UKHD8KTMF

if user was logged in and the role was assigned later this explains the behavior. session customer (not customer transfer) has a method to check if user needs refreshing and it will call zed by default. I would look there first.

Unknown

Do you experience the above behaviour consistently among certain customers or can any customer end up in a broken state?

UKTSRTD5M

I did not find any patterns for now

UKTSRTD5M

Hi again, we did now find a way to reproduce and therefore analyze deeper. The Problem is: after a customer ordering and getting marked as dirty the revalidation fails if the password has changed meanwhile. This seems to be a special case of a more general issue. I wonder if someone has had the same problem/requirement. If you change a b2b customer (e.g. permissions) they do not get updated until the session reloads - which to us seems like happens only once and for the session, the order happens from. If there is another session (e.g. glue or in our case for our native mobile app) these sessions don't get aware of the changes. Is there a known way to invalidate or 'mark as dirty' all sessions of the customer so they would update immediately?

UKHD8KTMF

We did something similar for a project where we were checking in permissions have changed and then forcefully refreshed the user. It was Yves only frontend and it worked flawlessly, but we were making calls to ZED and this made the website a bit slower

UKHD8KTMF

I am not sure if this would be something that would work in your case.

UKTSRTD5M

I had the idea of tracking all user sessions in redis (written on login) - to be able to look them up on these external change scenarios and add something to mark the as dirty. so we would just had to add a minor check on all pageviews - and only a more expensive check on these seldom occasions. What do you think of this?

UKHD8KTMF

Hmm, then you need to set session as dirty with custom logic and make logic that will first check redis and then make request to zed to get new permission - seems complicated

UKHD8KTMF

maybe modifying isDirty logic on session customer would be a better way - like in CustomerTransferSessionRefreshPlugin

UKHD8KTMF

adding another plugin that will check timestamp or something and refresh user once a minute or somethin

UKHD8KTMF

if I am not mistaken the same client is used by Glue so this way you will have a single place solution

UKHD8KTMF

checking user credentials on every request is just bad, because you are dealing with edge case

UKTSRTD5M

thanks for your input. I'm aware this is going to be complicated 😞

UKHD8KTMF

you can still do what you want but I would still put it into the plugin

UKHD8KTMF

checking part

UKTSRTD5M

This seems the correct place indeed. I would expect the flagging dirty part to be the challenge: first we need to find all relevant sessions and then we have to flag them as dirty. Either completely outside of the session (which would require some additional step other then loading the session) or changing a session from the outside, which seems a little hacky to me right now...

UKTSRTD5M

I also think one goal should be to keep the slowing down for the "regular" site-access as minimal as possible...

UKHD8KTMF

I would just add a timestamp to the session user object and then check it

UKHD8KTMF

Once a minute is quite reasonable and this way all the complexity goes away

UKTSRTD5M

but what would you check? Would need to be a timestamp comparison or something like that, right? Session Customer vs last modification?

UKTSRTD5M

Or would you reload all permissions every minute?

UKHD8KTMF

I would just reload permissions