due to the fact that my users have configured their sessions to reopen each time they reopen their firefox browser. the 'session' cookies come back.
but my website needs fresh authentication if the session cookie is not present or 24 hours old. so I am having this problem of needing to manually remove the expired cookies each time i reopen browser after 24 hours.
to combat this, i tired to put a 'Logout' link on my page which should have helped me. but unfortunately it is not helping...
i tried below code to remove the cookies, but it seems it does not remove the cookies from the sqilte table in which firefox stores its cookies. After the following code is run, cookies reappear.. (or are they not getting removed???) how can i achieve that?
code:
function Delete_Cookie( name, path, domain )
{
document.cookie=name+"="+((path) ? ";path="+path:"")+((domain)?";domain="+domain:"")+";expires=Thu, 01 Jan 1970 00:00:01 GMT";
}
$("#Logout").click(function() {
Delete_Cookie('SecOne','/','.mydomain.com');
Delete_Cookie('SecTwo','/','.mydomain.com');
alert("Bye");
});
Although I can't say for certain what the problem is, there are a few possibilities:
The domain name could be wrong.
You could write a test delete line that doesn't use the path and domain names and see if it works then. If the cookies get deleted after that change, then it's the string you made for the delete line, or the parameters that are passed in that are wrong.
Also, perhaps it is possible another section of your code is causing the cookies to reappear. Check to see if there's any other cookie setting things that get called after this is.
Or maybe the page needs reloaded in order for the cookies to disappear
If the cookie is HttpOnly cookie, it is not able to read/delete from HTTPS secured webpage. If the cookie is normal one, below functionality can be used for delete cookie.
function deleteCookie(keyName){
var allcookies = document.cookie, i, cookiearray = null, name = null;
cookiearray = allcookies.split(';');
for (i = 0; i < cookiearray.length; i++) {
name = cookiearray[i].split('=')[0].trim();
if (name === keyName) {
document.cookie = name + '=000;expires=Thu, 1 Jan 1970 00:00:00 UTC; path=/';
}
}
}
Note: Session cookies are not able to delete even browser is getting closed. This is known bug in chrome browsers. Refer below link
Cookie issue in chrome
I know this is an old thread but I was having the same problem as I kept trying to set a cookie with a time in the past, thinking it would expire and not show in FF cookie manager.
Setting the cookie to expire in the future but having a blank value got rid of it. Not sure why.
setcookie(mycookie,"", time()+5000,'/');
Using FireFox v40.0.3
Seems there have been a few bugs logged with Firefox and it's handling of cookie expiration.
Related
I'm losing my mind here - I'm looking into an issue where some signout functionality in an application I have isn't working because the authentication cookie is not being cleared. The thing is that our "signout" endpoint does include the appropriate set-cookie header in the response - here's what I get looking at the raw response in Firefox:
set-cookie: Auth.myapp=; domain=app.mydomain.com; expires=Thu, 26-Nov-2020 13:19:20 GMT; path=/; secure; HttpOnly
Firefox is reporting this error in the console:
Cookie “Auth.myapp” has been rejected because it is already expired
This is kind of confusing, not only have I successfully used set-cookie with a past-date in expires before, it's even codified in RFC6265 as the accepted way to request a client remove a cookie:
Finally, to remove a cookie, the server returns a Set-Cookie header
with an expiration date in the past. The server will be successful
in removing the cookie only if the Path and the Domain attribute in
the Set-Cookie header match the values used when the cookie was
created.
So I need to set an expires date in the past to clear the cookie ... but doing so causes the browser to reject it? Does anyone know what's going on here?
To be clear I have checked that the cookie name, path, secure and SameSite match (update: I suspected that because I hadn't explicitly specified a SameSite this might be the cause, but after making sure the cookie is both set and cleared with SameSite=None it is still not working).
As far as I can tell, the message is harmless - the cookies are indeed deleted based on my testing. And Googling the message leads to this changeset, which indicates that the deletion does happen, just with additional logging.
// If the new cookie has expired -- i.e. the intent was simply to delete
// the old cookie -- then we're done.
if (aCookie->Expiry() <= currentTime) {
COOKIE_LOGFAILURE(SET_COOKIE, aHostURI, aCookieHeader,
"previously stored cookie was deleted");
+ CookieLogging::LogMessageToConsole(
+ aCRC, aHostURI, nsIScriptError::warningFlag,
+ CONSOLE_REJECTION_CATEGORY, "CookieRejectedExpired"_ns,
+ AutoTArray<nsString, 1>{
+ NS_ConvertUTF8toUTF16(aCookie->Name()),
+ });
NotifyChanged(oldCookie, u"deleted", oldCookieIsSession);
return;
The message seems unnecessary however, and there is a bug report about it.
This occurs when using a null , false, or empty string in the cookie value.
It is only flagged as a warning in Firefox.
Other browsers do not show this warning.
I'm having a similar problem today with the same error message as the OP.
This happened in the past and my solution then was, rather than setting a time in the past, I set the value to nothing (as a failsafe) and also set 'expires' to 'time() + 1' (so a future time with the cookie expiring almost instantly).
setcookie('cookiename','',[
'expires' => time() + 1,
'path' => '/',
'domain' => $_SERVER['HTTP_HOST'],
'secure' => true,
'samesite' => 'strict'
]);
Unfortunately, this workaround seems to suddenly be failing today and that failure does seem to be unique to Firefox. (So, yup, perhaps an FF bug?)
Chrome and Vivaldi are still working fine with it. I didn't test on Safari nor Edge as yet.
I found a strange cookie problem on safari. If you surf to http://2much.ch you can enter with FF/IE and surf inside the site.
But if you use safari, you can enter only once; you can't surf inside the site. I found that Safari doesn't set the entered cookie, but FF/IE does.
What is wrong here?
It looks like you hit a Safari bug here; you are redirecting any visiting browser to /entry while setting the cookie at the same time, and Safari is ignoring the Set-Cookie header when encountering the 302 HTTP status:
$ curl -so /dev/null -D - http://4much.schnickschnack.info/
HTTP/1.1 302 Moved Temporarily
Server: nginx/0.7.61
Date: Sun, 19 Jul 2009 12:20:49 GMT
Content-Type: text/html;charset=utf-8
Connection: keep-alive
Content-Length: 14260
Content-Language: de
Expires: Sat, 1 Jan 2000 00:00:00 GMT
Location: http://4much.schnickschnack.info/entry
Set-Cookie: colorstyle="bright"; Path=/; Expires=1248092449.12
Set-Cookie: _ZopeId="73230900A39w5NG7q4g"; Path=/
Technically, this would be a bug in Apple's Foundation Classes, I've found a WebKit bug that states this is the case.
I suppose the workaround is to set the cookie not in index_html but in entry instead.
In the intervening years since I first answered this question, this issue now appears solved, at least it was for Safari 6 when someone tested all major browsers for Set-Cookie support on 302 redirects in 2012.
A month ago, I ran into this issue. At first I thought it was a corrupted cookie jar as I could clean out the cookies and go.
However, it popped up again. This time I spent an hour going through it, watching what was sent, reviewing what safari sent back, and I found the problem.
In this case, I had an array of cookie values being sent to the browser after login prior to the redirect. The values looked something like 'user id', 'user full name', 'some other id', etc.
( yes, the id's are encrypted so no worries there )
My user full name was actually in a <lastname>, <firstname> format.
When safari was posting the cookie back to the server, everything after the comma after the lastname was dropped. It was only posting back values up to that point.
When i removed the comma the rest of the values started working just fine.
So it appears that if you send a cookie value that contains a comma, then safari doesn't properly escape that in it's internal storage. Which leads me to think that if they aren't properly escaping commas, then there are probably some security issues with safari's cookie handling code.
Incidentally, this was tested on Win 7 x64 with safari 4.0.5. Also I put up a web page at: http://cookietest.livelyconsulting.com/ which shows this exact problem.(I removed that test site)
IE, FF, and chrome all correctly set the cookie. safari does not.
Looks like this is no longer an issue. See http://blog.dubbelboer.com/2012/11/25/302-cookie.html
We've run into a very similar issue where Safari (v. 7.0.6) would ignore a cookie. The cookie header looked perfectly fine, almost identical to another cookie which was remembered.
It turned out that the culprit was the previous cookie header having a malformed expires value. Safari's handling of broken cookie headers is evidently not as robust as that of the other browsers.
I ran into same issue with Chrome. Chrome doesn't ignore the set-cookie header while you are redirecting, but you never know the order (set cookie first or redirect first). Here is something I have tried:
I have a website, which supports English and French. I implemented it (with php) this way:
localhost has a link to localhost/fr (which set-cookie to French and redirect to localhost). It works. (set cookie first)
localhost/path1 has a link to localhost/fr?return=/path1 (which set-cookie to French and redirect to localhost/path1). It doesn't work. (redirect first, the language didn't change)
localhost/path1 has a link to localhost/fr?return=www.google.com (which set-cookie to French and redirect to google). When I came back to my website again, it's in French. (which means set-cookie to French is not ignored, only executed after redirect)
Hope I make myself clear, English is a foreign language to me.
After a great deal of pain, I found out that Safari (15.3) actually does save and my cookie, but it never displayed in developer tools storage -> cookies, but it works fine.
Here's the cookie I create and return in a Netlify function.
const secureCookie = cookie.serialize('jwtToken', JSON.stringify(jwtToken), {
secure: process.env.CONTEXT !== 'dev',
domain: process.env.CONTEXT === 'dev' ? 'localhost' : '.domain.com',
httpOnly: true,
sameSite: true,
expires: new Date(Date.now() + (1000 * jwtToken.expires_in))
})
and netlify function return
return {
statusCode: 200,
headers: {
"Cache-Control": "no-cache",
},
multiValueHeaders: {
"Set-Cookie": [secureCookie],
},
body: JSON.stringify(body),
}
Using latest version of cakephp v2.3.3
I have a problem with my session variables when a browser doesn't allow cookies.
I pass variables from one controller to the other and this works perfect as long as the browser has cookies enabled. I have tried it with the Session helper in the controllers, but no effort, same problem.
How to fix this, is there a work around???
Cookies are required to keep track of the session ID, but you can manually get or set the session ID using $this->Session->id(). By adding the code below to the App Controllers' before filter you can set the session ID as a URL paramter like http://example.com/posts/view/1?session=qkv108c2pqeubcpeos1q7ekds3, for example.
if (!empty($this->request->query['session'])) {
$this->Session->id($this->request->query['session']);
}
The session ID is required for every request which means you have to include it in every link. I would suggest extending the HTML helpers' url and link methods to automatically add it.
Edit:
You should verify that $this->Session->read('Config.userAgent'); or $this->request->clientIp(); has not changed since the user was authenticated to prevent session hijacking. Thanks to thaJeztah for pointing this out.
Right now I'm using this:
location ~* \.(js|css)$ { # |png|jpg|jpeg|gif|ico
expires max;
#log_not_found off; # what's this for?
}
And this is what I see in firebug:
Did it work? If I didn't get it wrong, my browser is asking for the file again, and nginx is answering 'not modified', so my browser uses the cache. But I thought the browser shouldn't even ask for the file, it already knows it will never expire.
Any thoughts?
Do not use F5 to reload the page. Use click on the url + enter, or click in a link. That's how I got only 1 request.
Clearly , your file is not stale as its max-age and expiry date are still valid and hence the browser will not communicate with server.The Browser doesn't ask for the file unless it is stale. i.e. its cache-control ( max -age) is over or Expiry date is gone. In that case it will ask the serve if the given copy is still valid or not. if yes, it will serve same copy, else it will get new one.
Update :
See, here is the thing. F5/refresh will always make browser to request the server if anything is modified or not. It will have If-Modified-Since in Request header. While it is different from just navigating the site, coming back to pages and click events in which browser will not ask server , and load from cache silently( no server call). Also, if you are testing on firefox Live HTTP Headers, it will show you exactly what is requested, while Firebug will always show you If-Modified-Since. Safari's developer menu should show load time as 0. Hope it helps.
I'm still new to code igniter and I'm having problems getting the login system to work.
The login always works when I use Firefox. The login consistently works on some IE7 browsers but consistently fails on other IE7 browsers.
When tracing the code, I see that the models/redux_auth_model.php does successfully authenticate the user, it writes user information into the $this->session->set_userdata() and it redirect them to a member's page of my choosing. Here's the code:
public function login($identity = false, $password = false)
{
$identity_column = $this->config->item('identity');
$users_table = $this->tables['users'];
if ($identity === false || $password === false || $this->identity_check($identity) == false)
{
return false;
}
$query = $this->db->select($identity_column.', email, password, group_id')
->where($identity_column, $identity)
->where('active', 'Active')
->limit(1)
->get($users_table);
$result = $query->row();
if ($query->num_rows() == 1)
{
//$password = $this->hash_password_db($identity, $password);
if (!empty($result->activation_code)) { return false; }
if ($result->password === $password)
{
$this->session->set_userdata($identity_column, $result->{$identity_column});
$this->session->set_userdata('email', $result->email);
$this->session->set_userdata('group', $result->group_id);
return true;
}
}
return false;
}
I did a variable dump of $this->session in both IE7 and FF and confirmed that all the userdata is intact before the redirect. The session had my email information, group information and $identity_column information.
However, after the redirect, the session data is empty on some IE7 browsers, which is why CI keeps booting me out of the system. It's fully intact on other IE7 browsers and always intact in Firefox.
Why would session data be browser dependent?
Any ideas on how to troubleshoot this further? I am baffled...
It is a frustrating problem with the Codeigniter database session class, in the end I resorted to using native sessions using the drop-in replacement found here: https://github.com/EllisLab/CodeIgniter/wiki/Native-session
I was having the same problem while using CI Session in IE. Then I use the below header in controller constructor and it works for me.
Here is the header:
header('P3P:CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"');
I faced the same problem while using IE8 with browser mode. I've found the problem is in matching the user agent. In session database it saves useragent as IE7 but from cookie it gets IE8. I've set $config[sess_match_useragent] = FALSE and the problem is solved.
The session class works fine in several of my projects including IE6/7/8 support (including multiple releases of CI). There are a few things that might be causing this, outside of the code pasted above:
Calling $this->session->sess_create(); from a baseclass (or elsewhere in your class's code) would reset your session.
Try combining your set_userdata calls to one call by passing it an array.
Make sure your data does not have any unexpected characters in it (this can cause issues in certain browsers).
Make sure your session class settings in the config are not rolling over the cookie every request.
Alternatively, consider an alternate session class like Native sessions
This is an issue that someone made a 3rd party fix for, it patches the session controller. Let me dig it up. I have used it in my codeigniter setups since it was first noted.
This issue is IE7/IE8 specific with redirects or frames.
EDIT
Here is the reference that I have found before, it helped me with the IE issue. Hopefully this is what is causing you headaches:
http://www.philsbury.co.uk/blog/code-igniter-sessions
It's a problem with browsers. I put this in MY_Controller in constructor:
header("Cache-Control: no-store, no-cache, must-revalidate, max-age=0");
for example:
if($this->uri->segment(1)=='admin') header("Cache-Control: no-store, no-cache, must-revalidate, max-age=0");
We were developing an app involving a Facebook tab when we ran into this problem. We tried the above to no avail. Here's what we found out:
IE privacy settings seem to have to be medium or less
If your running a page app, make sure BOTH URL's have HTTPS protocol in them
Also, look into the Compact Privacy Policy for cookies.
config file application config.php
// 'cookie_secure' = Cookies will only be set if a secure HTTPS connection exists.
$config['cookie_secure'] = FALSE;
I solved this by using native php session instead of cookies (Storing codeigniter session_id in php native session).
You can grab library here: https://github.com/staskus/codeigniter-2.--native-session.
Just copy MY_Session.php file into applications/libraries
The problem is IE denying the cookie CI is trying to set. Native sessions is one way, however if you want to keep using CI sessions I have had success with the following troubleshooting:
Check that setting $config['cookie_domain'] in config.php is not empty
Remove the underscore from $config['sess_cookie_name'], for example change "ci_session" to "cisession"
Check that the server time is correct
I hate IE !!!
its working now giving P3P to our controllers fix the problem :
class Chupacabra extends CI_Controller {
function __construct() {
parent::__construct();
header('P3P:CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"');
}
This issue plagued me when I was trying get a login page to work in CodeIgnitor. The session would not save.
It turns out that it was due to a domain name that I created from FREEDNS that contained an underscore (_). I renamed the domain name using a period (.) and reverted all the code changes that were suggested in this post, and Voila, it worked.
Thanks for all the comments and contributions on this page because they really led me down the road of investigating that darn underscore.