There's a Cookies subsection under the Resources tab in DevTools... right clicking on any of the cookies gives me a Clear option. But is this the same as deleting the cookie, or will it just clear the contents? The UI does not remove the cookie from view, it just shows empty content.
Sometimes I may check for the existence of a cookie instead of reading the data from it to verify, so this is a matter of consequence.
I think what you call a cookie is actually a site. If you click on a site, you get a list of actual cookies for this site on the right side of the window with their name, contents, size etc... Each line is a cookie. You can delete individual cookies there.
When you clear a site, it deletes all the cookies from this site in one click, but as you can't delete a site, it still shows on the left side of the window.
Delete/Clear all features remove cookies completely. You can test it quite easily yourself:
open the Console
type document.cookies
remove a cookie using Resources tab
type document.cookies again and compare the output with the previous one
You will find out that cookie you removed with Resources was removed completely.
Related
I have two different installations of TYPO3 10.4.27 and try to remove all cookies.
I wonder why on one site having a contact-form, the fe_typo_user cookie is set and on the other site with the exact same form.yaml definition, it isn't set a cookie.
Additionally, I have a page, where a be_typo_user is set, without me doing this intentionally. - Edit: I found this one in my own code. Instantiated "BackendUserAuthentication"
It seems to be "normal" to have the fe_typo3_user cookie set on pages with forms. When I delete it once and reload the page it depends on the Typoscript setting config.no_cache whether the cookies are set again or not. With config.no_cache = 0, the cookies won't be set again. With config.no_cache = 1 (which you shouldn't be set) the cookies come again and again while doing "delete cookies => reload page". So I recognized, that with a "fresh" browser visiting the site I previously saw no cookie, there is one, too.
I can reproduce this behavior on any typo3 v9/v10 site on a page with a form by deleting frontend cache and loading it with another browser afterwards.
Can I get rid of those cookies? Are they DSGVO relevant for sites without cookie banner?
On the one site with cookies I had config.no_cache = 1 (which you shouldn't be set), the other had the default value config.no_cache = 0.
I additionally tested it with two browsers.
Clear Frontend Cache
Hit the page with form in one browser getting cookie set
Hit the same page in another browser getting no cookie
In Chrome Dev Tools > Application under Cookies I see a list of URLs. When I hover over each one, Chrome shows the message "Cookies used by frames from X".
At first, I assumed that frames meant "iframe", i.e. if an iframe was used on this webpage from source X, then any cookie set by visiting that (iframe view of the) site would show up in the dev tools for your inspection. However, I checked to see if there was always a corresponding iframe for each source, and that is not the case.
So my questions in summary are:
what does "frame" mean in this context?
Why are these cookies almost always empty? For example, I'm looking right now at "Cookies used by frames from https://www.facebook.com", and it's empty.
As mentioned in Chrome DevTools documentation:
When you expand the Cookies category, it displays a list of domains of
the main document and those of all loaded frames. Selecting one of
these "frame groups" displays all cookies, for all resources, for all
frames in that group. There are two consequences of this grouping to
be aware of:
Cookies from different domains may appear in the same frame group.
The same cookie may appear in several frame groups.
Here is a more explicit explanation from Mozilla Storage Inspector documentation (although it isn't Chrome, the concept is similar):
Cookies — All the cookies created by the page or any iframes inside of
the page. Cookies created as a part of response of network calls are
also listed, but only for calls that happened while the tool is open.
So, basically, you will see the main document's domain and all its iframes.
About the "empty" frames with no corresponding frame
It is interesting. It is related to the Preload pages for faster browsing and searching example or Page Prefetch or prerendering feature that Chrome has.
This feature is under Chrome settings > Privacy and Security > Cookies and site data.
What this feature does is prefetch links on the page that you are probably gonna click. This allows the page to load a bit faster when accessing it.
If you dig in their docs you will find this:
Prerendered requests will use a ChromeURLRequestContext which has a
new CookieStore interface, but is otherwise the same as the current
profile’s ChromeURLRequestContext. If the PrerenderContents are
discarded without being used, the changes made to the CookieStore
interface go away. Otherwise, the deltas will be committed to the main
CookieStore for the profile. If there is a merge problem, the
prerendered page is discarded and a fresh request is issued.
This means that for the prerendered requests using a different CookieStore - this is the reason that it's empty on your main profile DevTools. It stores the cookies in a different store and merges them to the main store after you actually click on the link.
I am working on web app in OutSystems 10.0. In the application, if I log out, it logs off. But when I click the browser back Button, it redirects to the Previous page (which should be displayed only after login). Any suggestions?
You probably need to have roles on the pages, if the pages have the role anonymous anyone can open it.
You're probably accessing the website via http and not https, so when you press back on the browser it will show you a cached version of the previous page.
Because it's the cached version, the session and roles are not checked.
As a recommendation, force the https protocol.
Following the link provided by #Abdulhakeem, they recommend the following:
Add a hidden input to the page - initialize it to some value (for example 'no') - so when the page is rendered by the server it always has a 'no'
Add a bit of Javascript to the page ready event to:
Check that value - if it's not what you'd expect from the server (in our case, <> 'no'), force refresh the page (see below)
If it is still set to what you'd expect from the server, change it (in our case to 'yes') and do nothing else
I recommend downloading the .oml provided in the post and reviewing how they actually implemented it.
if you can change to https, you can also in every action that is on the page that do changes on the database. check if you have permissions or you are logged. that way if the person tries to do back and do some action you can redirect it somewhere.
I have just migrated a site to a new domain (with new design) and am redirecting from the old site to the new with .htaccess and redirect 301. Since the new site is quite different, I'm concerned that users might be disoriented. Is there a way to have a popup on the new site that users get only if they have been redirected from the old site? Have been searching on this but keywords seem to lead only to stuff on popup redirects to another site.
I can think of several ways to do it:
Redirect in the 301 to another page (www.blah.com/tour instead of www.blah.com) and there i would put the logic to show the popup
Redirect in the 301 to another page and there set a cookie and redirect to the original page. Then, add logic to the original page to show the popup if the cookie is present (and delete the cookie)
Check the referrer in the new site and if it matches the old one, show the popup
Your problem boils down to detecting a request that has come via a 301 redirect - popups and usability are a separate (simpler?!) issue.
Unfortunately, detecting a 301 redirect is one of those inexact things that requires a mixture of techniques to get near to 100%. I say near, but never quite there - a bit like browser detection.
One option is to append a querystring (GET) parameter to the redirected URL, e.g.
www.example.com/LandingPage.html?isRedirected=true
You could also set the same info in a cookie (but won't work if cookies are disabled or cleared).
Another option is checking the Referrer header - but again, these may differ based on browser implementation and can be faked, although if someone's faking a redirect I don't think you need to worry about guiding them through your new design!
I want to do history token rewriting. Don't know its possible or not.
e.g. If my application URL is http://localhost:8080/myapp/#login which contain 'login' as history token. Is it possible to rewrite the URL like http://localhost:8080/myapp/user/login.
Or is it possible to remove '#' from history token?
The # token has special meaning in an URL. The browser interprets everything before the # token as the page to load, and everything after the # as additional information for on the page. This means if something is changed in the URL after the # token, the webpage is not reloaded, but it does create a browser history item. GWT uses this to create new history items, while not reloading the page.
If you would rewrite the URL from #login to /user/login you would instruct the browser to reload the page, which means the whole GWT page is reloaded and all state information is reset. This is probably not what you want.
So the short answer is, although it's technically possible, it will change the behavior from a one page website to a multi-page website that reloads every time the history changes, and that's probably not something you want.