What are the Slack Archives?
It’s a history of our time together in the Slack Community! There’s a ton of knowledge in here, so feel free to search through the archives for a possible answer to your question.
Because this space is not active, you won’t be able to create a new post or comment here. If you have a question or want to start a discussion about something, head over to our categories and pick one to post in! You can always refer back to a post from Slack Archives if needed; just copy the link to use it as a reference..
Hello, we have some unexpected behaviour we cannot follow for now. For some reason we sometimes have
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?
Comments
-
How is your session redis built?
0 -
can that be that these are “old” sessions that were created before you’ve introduced UsernamePasswordToken into them?
0 -
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...
0 -
customer is refreshed in session data
0 -
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.
0 -
Do you experience the above behaviour consistently among certain customers or can any customer end up in a broken state?
0 -
I did not find any patterns for now
0 -
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?
0 -
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
0 -
I am not sure if this would be something that would work in your case.
0 -
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?
0 -
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
0 -
maybe modifying isDirty logic on session customer would be a better way - like in CustomerTransferSessionRefreshPlugin
0 -
adding another plugin that will check timestamp or something and refresh user once a minute or somethin
0 -
if I am not mistaken the same client is used by Glue so this way you will have a single place solution
0 -
checking user credentials on every request is just bad, because you are dealing with edge case
0 -
thanks for your input. I'm aware this is going to be complicated 😞
0 -
you can still do what you want but I would still put it into the plugin
0 -
checking part
0 -
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...
0 -
I also think one goal should be to keep the slowing down for the "regular" site-access as minimal as possible...
0 -
I would just add a timestamp to the session user object and then check it
0 -
Once a minute is quite reasonable and this way all the complexity goes away
0 -
but what would you check? Would need to be a timestamp comparison or something like that, right? Session Customer vs last modification?
0 -
Or would you reload all permissions every minute?
0 -
I would just reload permissions
0
Categories
- All Categories
- 42 Getting Started & Guidelines
- 7 Getting Started in the Community
- 8 Additional Resources
- 7 Community Ideas and Feedback
- 84 Spryker News
- 977 Developer Corner
- 828 Spryker Development
- 91 Spryker Dev Environment
- 362 Spryker Releases
- 3 Oryx frontend framework
- 36 Propel ORM
- 68 Community Projects
- 3 Community Ideation Board
- 30 Hackathon
- 3 PHP Bridge
- 6 Gacela Project
- 32 Job Opportunities
- 3.2K 📜 Slack Archives
- 116 Academy
- 5 Business Users
- 370 Docker
- 551 Slack General
- 2K Help
- 75 Knowledge Sharing
- 6 Random Stuff
- 4 Code Testing
- 33 Product & Business Questions
- 70 Spryker Safari Questions
- 50 Random