How can I deactivate the fe_typo_user cookie in TYPO3 7.6. I don't use fe_login or other data stored in sessions on this website, but the cookie is set. The website was updated from an earlier TYPO3 version. In this issue another user had the same problem with an updated version - as solution he obviously used a fresh installation of TYPO3.
Isn't there another way to deactivate this cookie if not used? In earlier versions it worked with
["FE"]["dontSetCookie"] = 1
but in 7.6. obviously not anymore.
Edit:
The cookie is set new. I deleted it in chrome developer tools. You could check this webiste. I use powermail for contact forms, but as far as I know it doesn't set cookies. For tracking Piwik/Matomo is used, but it has it's own cookies "outside" of TYPO3. Conditions aren't used.
Which version of powermail are you using?
Since v6.0 the session-spam-check is disabled by default.
From release notes:
Task: Disable session-spam-check by default (to prevent generating a cookie)
Are you sure the cookie is set new?
You need to identify where you have user-dependent configuration which might set the cookie.
Do you have forms or interactive elements in the site?
Do you have conditions in your configuration?
Do you use tracking tools?
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 tried to prevent cookies for identifying the session in RAP. There are a lot of sources.
The most important are obviously this and that one. It seems the jettycustomizer disappeared. Which JVM parameter would I have now to supply to force Jetty out of Eclipse not to use cookies.
The given option
-Dorg.eclipse.equinox.http.jetty.customizer.class=org.eclipse.rap.jettycustomizer.internal.SessionCookieCustomizer
doesn't work for me.
AFAIK, you can't disable session cookies in Jetty by means of declaration, you need to do it programmatically. According to this post, the following code does the trick:
((HashSessionManager)context.getSessionHandler().getSessionManager())
.setUsingCookies(false);
The RAP project used to provide a fragment bundle for jetty that contains a customizer class which disables sessions using this method. This customizer has to be enabled with the system property you referred to, but this only works when the fragment is present in your environment.
This “jettycustomizer” bundle has been dropped when RAP enabled support for multi-tab browsing, but you can still get it from the 2.1 branch.
Recently I have create some UI tests for a qooxdoo application with the built-in simulator ( I am using qooxdoo 3.0.1, selenium-server-standalone-2.35.0 and firefox23)
and I need to store a cookie in the browser and save that for the next time that it open.
code that stores the cookie:
if(!this.getQxSelenium().isCookiePresent(debugVariable))
this.getQxSelenium().createCookie("debugVariable=0","path=/, max_age=350000, domain=subdomain.foo.com");
console.log(this.getQxSelenium().getCookieByName("debugVariable"));
I have find that there is an argument in the server the -profilesLocation that specifies the directory that holds the Firefox profiles that java clients can use to start up the Firefox
I even try to use -browserSessionReuse but it does not working either for me.
I see this is not enough what other solution I could try to make the Firefox to remember the cookies?
This is not a qooxdoo-specific issue. I tried it with a plain HTML+JS page and Selenium's -firefoxProfileTemplate option and it didn't keep the cookie either.
You could try using an older version of Selenium (and perhaps also Firefox). -firefoxProfileTemplate is specific to Selenium RC, which is deprecated and gets more broken with every new release.
When we set the addAspxExtension web.config setting to true for our website, debug mode stops working for all pages of our site except for the homepage. When I say that it stops working I mean that it displays the actual page but without the Sitecore ribbon and profiling information.
I guess we could apply this setting only in our content delivery environments and leave it on (addAspxExtension="true") for our content entry environment but I was wondering if anyone has managed to get around this issue?
Update
Until Sitecore resolves this issue I have decided to only set the addAspxExtension setting to "true" in our Preview and Production environments. That way the debug mode will still work in our development environment.
As of right now, this issue is a bug that Sitecore is aware of and should hopefully be fixed by the next update. There are basically 2 workarounds for it:
Set the addAspxExtension attribute to “false” value.
Manually write the .aspx extension to other URLs which are different from the home page.
Hope that helps..
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.