I am facing very interesting issue and I am not sure what can cause this. I am using SSO SAML for authentication to the system and IE11 as the browser to access the application. After some time (e.g. 5 min) the session terminates and it is renewed and it is a background process. Somehow only in IE, the session is not renewed until I maximize the browser and do some user action (after that it works). Other browsers are not affected and everything works in background properly. Do anyone know what can cause the issue in IE that the browser needs to user action?
Very weird issue.
Im logged into Laravel app with 2 different users in Chrome and Chrome Incognito.
When I submit {any} update form it logs the other user out when I refresh.
The user that I submitted the form with is still logged in.
When simply browsing around both users remain logged in.
Environment
Windows XAMP
session drive = redis (I have tried changing this to see if it helps)
UPDATE:
Same thing happens when logged in from 2 seperate browsers - Chrome / IE
I presume something in the Illuminate\Http\Request class causes this behavior.
UPDATE 2
Keeps both users logged in when I select the "Remember Me" option.
similar issue: https://laracasts.com/discuss/channels/laravel/laravel-not-reading-session-cookie-on-form-post-in-chrome-when-logged-in-with-remember-me
Hints to being XAMP bug - using different dev environment solved it.
I think with it being such a weird issue - and not many people experiencing it must be a issue with my specific environment.
The sessions in PHP use a cookie (created automatically) that is stored by your browser, is very posible that the mode igcognito that you are using delete this cookie whe you refresh the page.
When starting the first Incognito window, it uses a completely brand new and blank internal profile that has no cookies nor session data. Any cookies or session info are set immediately during that session. Further Incognito windows opened all share that same session, so they share the cookies/session data.
I'm working on a cross-platform wxWidgets-based application that uses a WebView for a web-based OAuth login to a web site. The web site's OAuth login process uses cookies to cache a login token once authenticated, so that you can go through the process again to get another OAuth token if necessary without the user having to enter their credentials again. The WebView backend implementation wxWEBVIEW_WEBKIT that I'm using in the macOS version of the app preserves cookies between restarts of my app and even reboots of the OS. This makes it difficult to test the login process.
Where is the WebView backend persisting these cookies? How would I go about clearing them?
I've already tried clearing the cookies in Safari to no avail, and I removed all of the obvious cache files I saw in the app's file accesses as captured by opensnoop, but the cached login is still present.
Per a response on the wx-users list, wxWEBVIEW_WEBKIT is implemented using a simple macOS WebView.
As noted in How can I remove cookies stored by WebView in Cocoa application?, in macOS 10.11 (El Capitan) and later, each application's WebViews have their own cookie storage and do not have access to each others' cookies.
I did not find a way to manually clear my application's cookies; I tried removing the relevant *.binarycookies file from ~/Library/Cookies but that had no effect. It's still unclear to me where the cookies are stored.
However I was able to delete the cookies programmatically using the NSHTTPCookieStorage API, following the code snippet in https://stackoverflow.com/a/8486398/60422. I ended up just adding a menu item for this to my application to clear the cookies that I only use for manual testing purposes.
I use Devise in my Rails 3.1 application to manage sessions. In Safari and Firefox, the user is correctly prompted to login if he attempts to access a page that requires authorization. However, in Internet Explorer (versions 7 and 8), the user is correctly redirected to the login page, but logging in does nothing.
In other words, the username and password are correct, but it appears as if Internet Explorer can not set the session. Cookies are enabled for IE as well.
Has anyone experienced any similar session issues with IE? I just need to know where to look. I have already fought through IE's inability to handle pushState, it seems like IE is pretty difficult to code for.
Internet Explorer 9 seems to work fine.
Crossbrowser pushState with hashbang fallback: History.js.
AJAX requests without the XRSF token destroy the devise session, maybe IE is messing this one up with your code.
Remove all the history in Firefox (delete all cookies), disable all add-ons and plugins, then restart Firefox. Do not go to any site and wait for about 10-15 min. Go to Options->...->Show cookies. You will see cookie named PREF with google.com domain.
1) Can somebody explain how and why this cookie appears?
2) How to get rid of this?
p.s I don't have any google desktop application installed. Firefox google search bar is removed too.
This cookie is coming from Google's safebrowsing api:
google.com/safebrowsing/downloads?client=....
This is a known issue in firefox and there is an open ticket here:
https://bugzilla.mozilla.org/show_bug.cgi?id=368255
EDIT To get rid of it, you can turn off the safebrowsing on the security tab (under Options), by un-checking the boxes to Block attacks and forgeries.
Why does it appear?
As part of Safe Browsing, Web browsers ping Google periodically for
updated lists of potentially dangerous sites. When they do, Google
puts a cookie on the user’s machine. Google says the cookie helps it
keep its system stable and monitor for attacks.
Source: The Google Cookie That Seems to Come Out of Nowhere
Why does it keep reappearing even after I delete it?
Because you need to disable Safe Browsing
AND because Firefox Cookie Manager can't delete it, even if it appears to (bug #1026538).
Why is it dangerous?
As this cookie contains a unique ID number, it has been used by the NSA to track people under suspicion. Source: NSA uses Google cookies to pinpoint targets for hacking, Washington Post
Also, it means Google can track you better since this unique ID is persistent even after you close Firefox.
Security often means less privacy. You can avoid sending all your browsing history to Google: Use an up-to-date browser and modules, disable uneeded browser modules, don't install apps/modules from untrusted sources and avoid phishing attempts by checking the website domain and HTTPS certificate.
How to really get rid of it?
Disable Safe Browsing:
1.1 Uncheck "Block reported attack sites" under Firefox Preferences > Security tab
1.2. Uncheck "Block reported web forgeries" under Firefox Preferences > Security tab
THEN manually delete the existing cookie with sqlite3 (as long as bug #1026538 is open)
2.1. Find your Firefox cookie database within your Firefox profile folder:
Firefox menu > Help button > Troubleshooting Information > Application Basics section > Profile folder line > Open Directory button > File name is cookies.sqlite
or (Ubuntu) find ~/.mozilla/firefox -name cookies.sqlite
2.2 Install sqlite3: Download or (Linux) sudo apt-get install sqlite3
2.3 From command prompt: sqlite3path-to-cookies.sqlite
2.4 DELETE FROM moz_cookies WHERE baseDomain = "google.com";
Now you can check that the PREF cookie doesn't reappear at Firefox launch in Firefox Cookie Manager. It should not reappear as long as you don't re-enable Safe Browsing and if you have configured Firefox to delete cookies after exit.
Recommeded tools to limit tracking (except PREF cookie...): Cookie AutoDelete
It's used by the NSA and GCHQ to spy on people!
http://rt.com/usa/nsa-advertisers-cookies-track-browsers-034/
Google has updated their policies page to explain what types of cookies they use, specifically the PREF cookie.
But beforehand I will say that I can't explain where and how this cookie pops up in the browser. It seems to be done by firefox itself even if you don't use Google search, Google safebrowsing and block cookies for °.google.com
Google's policies page states that:
Preferences
...
The PREF cookie may store your preferences and other information, in particular your preferred language (e.g. English), how many search results you wish to have shown per page (e.g. 10 or 20), and whether or not you wish to have Google’s SafeSearch filter turned on.
Advertising
... Google uses cookies, like the PREF cookie, to help personalize ads on Google properties, like Google Search, particularly when you aren’t signed in to a Google account. ...
Maybe it's part of the undisclosed contract between Mozilla and Google to set this unblockable zombie cookie. Who knows? :-)
Click Show Cookies - Don't just delete the Google cookie but click 'Remove All Cookies' Remove the check mark from the 'Accept cookies from sites' box
It was possible to disable the google pref cookie in previous firefox-versions but since version 28 it is NOT possible to disable the google pref cookie! Mozilla integrated this cookie because google wants it - and google is paying millions of dollars for mozilla to keep this spying cookie in the firefox-browser enabled. Iam using now the comodo icedragon-browser, its based on firefox 26, you can install addons and themes from mozilla too, and most important you can disable the google-pref cookie: Go to options - privacy - enable custom settings - uncheck accepting cookies and remove the stored cookies if you have any (also add the links in which you login to the exception list). This cookie will never appear again. I hope Comodo dont update this browser to the newer ff-base.
I effectively deleted the google.com pref cookie. Do this:
about:config
safe
delete all values that reference google.com
It works and I've experienced no degradation in performance.
This, er, feature has undergone several rebrandings -- from "safe browsing" to "phishing protection" and now (FF 49) to "block dangerous and deceptive content". No doubt it will soon become "Protect tiny kittens".
Another way in Firefox is to click Exceptions under Options/Privacy/"use custom settings for history"; type in "google.com" and click Block. That way google.com will not be stored on your computer from then on. (If you have a gmail address, you can't access it unless you store google's cookie).