Using session.clear() doesn’t clear the cookies upon logout. Caching has been turned off. NO GLOBALS are being used anywhere.
It’s totally random when it happens. Just clicking around the site normally (always GET requests) and somehow users are ending up as other users.
SESSION_COOKIE_SAMESITE='Lax'
SESSION_TYPE = 'filesystem'
Cloudflare is on but do they even cache cookies?
We’re also using blueprints.
Any ideas where to look?
We added a check to flask_session to make sure the session data and cookie data are aligned before setting. This seems to have fixed the issue.
Related
We're integrating SAP Commerce 2005 and Spartacus 2.0.3 with CDS (Context-Driven Services). We followed the instructions from https://sap.github.io/spartacus-docs/cds-integration/ and we got it work right.
Nevertheless, we've noticed one issue.
When we clear the site data (either from Chrome DevTool or via browser Settings), the cookie named profile.consent.given is not being set anew while refreshing the page - even though the PROFILE consent has consentState "GIVEN" in local storage in spartacus-local-data > anonymous-consents > consents.
Initially I thought that it's just not visible in DevTools, but when I've added the url parameter ?profileTagDebug=true, in the console there is a log saying:
"[Profile Tag] No cookie found with name profile.consent.given".
When I set this cookie manually with value true, everything starts to work just fine, all other needed cookies and local storage data responsible for tracking users behavior is being set properly.
Do you see any place where we could have done something wrong, which may have caused this cookie to work improperly? Which module or component of Spartacus library would be of any clue in resolving this issue?
Edit: the reason of this strange behavior was in profile tag created by our team in CDS. It contained:
"consentListener": "type":"cookie","cookieName":"profile.consent.given","cookieValue":"true"},
which made the cookie profile.consent.given necessary while it shouldn't be. Using profile tag without this part made all work just fine.
With Spartacus, this cookie doesn’t make sense anymore. It is created by the Commerce backend and works best in combination with an accelerator frontend. Cds-spartacus in combination with ProfileTag relies on the anonymous consents or the user consents (depending on the user being logged in or not) loaded by Spartacus. More information about anonymous consents can be found here: https://sap.github.io/spartacus-docs/anonymous-consent/.
Just a quick FYI about the CDS-Spartacus integration: the profile tag script is pulled from the configured URL by Spartacus, and the script is doing all the event and data "scraping". The cookie is also being placed in the browser by the script.
Your question and this comment lead me to think that the script is not handling this case.
I'm not even sure if it should handle it, so it might be a better idea to contact CDS team directly about this one.
I need the ability to invalidate the Django session even if there is no Internet connection (or the server is down, or anything). The session cookie is by default httpOnly, and I don't like to change it, so simply deleting it is not an option. Is there any standard way to deal with this issue?
The relatively simple solution is to write a custom middleware on top of Django sessions. This middleware could add a secondary session token, say sessionid2, that would be acessible (and deletable) from Javascript. Both would be checked simultanously, so just one missing would invalidate the session. However, I would strongly prefer to use some of-the-shelf solution, if one exists.
The application is supposed to work as Chrome's Progressive Web App, so I'll be happy with a Chrome-specific solution if there is one.
I have a bit weird problem witch caching on my project in django.
I can edit my page-content in django-admin. When i do that and refresh site - nothing is happening. I have to wait few minutes for changes. Funny thing is that, when i change browser (or computer) - i dont have to wait - the changes are on. Is it the problem of django, browser or what? Is it possible to set setting.py to get changes immediately?
By the way, i have already figured out that when i turn the "django.middleware.cache.FetchFromCacheMiddleware" off - the problem disapears, but i dont want to turn cache off...
Any ideas?
When you have cache middleware enabled, Django caches the rendered template. When the next request is made, Django checks the cache for the template, and if it exists, it returns a 304 Not Modified rather than the normal 200 Found HTTP response. That tells your browser to pull it from its cache instead of pulling it down from the server again. (It's a lot more complicated than this in practice, but I'm simplifying).
Long and short, is this is how caching in Django works. If you don't want this behavior, then you can either disable the cache (not the cache middleware), by telling it to use the DummyCache backend:
CACHES = {
'default': {
'BACKEND': 'django.core.cache.backends.dummy.DummyCache',
}
}
This will result in Django always returning a 200 with a fresh copy because it can never find the cached copy. You can also add the following setting to settings.py:
CACHE_MIDDLEWARE_ANONYMOUS_ONLY = True
Then, if you're logged in (through admin or otherwise), the response will vary on that and always return a fresh copy. However, this will effect normal users of your site as well, if you have any public-facing login capability.
I've written a django application, and put it on a CentOS server. It is definitely okay when I use django development web server.
Such as I start it by "python ./manage.py runserver", and access that server from browser on another computer. I can sign in one time, and access all the pages without issues.
However when I run it with apache+mod_wsgi, I just found I have to login with user and password time by time. I think maybe there is some problem with the session middleware, so, how can I find the root cause and fix it?
There are a couple of different options for this.
In order of likelyhood (imho):
The session backend uses the cache system to store the sessions and you're using the locmem cache backend
The session backend isn't storing the cookies (secure cookies enabled? cookie timeouts? incorrect date on the server?)
The session middleware might not be loaded (custom settings for production server?)
Storing the session in the cache is only a good solution if you use memcached as the cache backend. So if you're storing the sessions in cache, make sure you use memcache :)
Either way, check if SESSION_ENGINE is set to django.contrib.sessions.backends.db
I have a handful of users on a server. After updating the site, they don't see the new pages. Is there a way to globally force their browsers and providers to display the new page? Maybe from settings.py? I see there are decorators that look like they do this on a function level.
Depends on browser and cache settings.
There may be no way to tell browsers to do so (as pages are cached, they are not even talking to server, so there is nothing You can do there).
Good trick is to set Vary: Cookie header, so You can always invalidate cache (by changing cookie somewhere) in case of need.
One way to force the browser to load a new page rather than loading the cached version is to change the file name. You could add a date/time to the file name and use a rewrite rule (assuming Apache web server here) to get the new page.
This site gives a quick explanation: http://www.askapache.com/htaccess/mod_rewrite-fix-for-caching-updated-files.html
and google will show many more.
you may also have to examine your cache control headers.