I'm developing an application in Joomla! 3.x which uses JWT cookies to grant some privileges. Everything works fine with Chrome, Firefox and Safari, but when it comes to Opera, my cookies are truncated.
How I set the cookies:
$inputCookie = JFactory::getApplication()->input->cookie;
$inputCookie->set("myCookie", $myCookie, 0);
Instead of a well-formed base64 encoding of a JWT, which I get on every other browser, Opera shows me only this:
o42io94enaeq3ellgfnafhdun3
Deleting the cookies does not work, since the cookie is always truncated when it gets stored.
Additional informations: Opera version is 46 on Mac. Using Opera 46 on Windows I have no problems with cookies.
It was the cache's fault. I still don't understand exactly what happened but it was simply solved by switching to private browsing.
The application uses redirects along with cookies and Opera probably cached some partial information (I still don't get how it managed to have only half a cookie, though). Switching to private browsing or otherwise deleting cookies and cache forced Opera to accept the whole cookie and everything worked. It seems to happen every few (about two or three) visit on the page.
Related
Really weird bug. I'm running MAMP Pro on my development computer, and I have a really simple test PHP program that looks like this:
<?php
session_start();
var_dump($_SESSION);
And the program works where ever I put it on my server, dumping out the session variables. UNLESS, the directory name starts with "ads" (then it just outputs an empty array).
http://domain/test.php - works
http://domain/ads/test.php - doesn't work
http://domain/adtest/test.php - works
http://domain/adserve/test.php - doesn't work
http://domain/sads/test.php - works
I don't have any .htaccess file doing anything with "ads".
Update: I did some more testing and found that this is only happening with Safari (not in Chrome or Firefox). But Safari is the main browser that would be used for this site. I don't want to change the name of the entire directory just to squirm around some Safari quirk if I don't have to. I've tried restarting Safari with no luck.
sessions in php use cookie so you need to check if your your safari browser allowing cookies and send a session id cookie back to the server
So when I wasn't experiencing this in any other browser, including Safari on other machines, I just deleted all the related cookies from the Safari on my development machine, and everything started working again. No idea what would cause the bug, but at least it was an easy enough fix in the end.
Edit: the problem came back a few days later, so I had to delete cookies again. I certainly hope this doesn't happen on others' browsers.
I have XAMPP 2.5.8 for Windows running on Win 7 as a development platform and just recently I lost the ability to set cookies (PHP) to expire in the future (they expire at the end of the session).
I was having a lot of problems with phpMyAdmin and upgraded it to 3.5.1. I don't know if this has anything to do with my cookie problem, but it was in the same time frame.
I've tried multiple browsers and verified that my system time is what PHP sees, but with no success.
I would double check the expiration time, cookie path and the domain.
You could also check if the client is overriding this behavior. e.g Firefox has an option called "Keep Cookies until I close Firefox" (Tools -Options -Privacy -Cookies) which could be having an effect.
First off, I'm not sure whether this is a problem in Opera 12.01 or not, but the problem only occurs in Opera. I've tested in FF14, Chrome 21, Safari 5 (Windows) and Safari Mac and Webkit browsers on Android and iPhone.
My application runs on the trigger.io forge platform and uses a proxy to route requests from the web application to the service. The proxy simply forwards the requests and cookies along and this works as expected in most of the browsers.
After inspecting the request in dragonfly, I noticed that the server sends the proper headers in the response, but Opera seems to be ignoring setting the values. I'm wondering whether this is due to some misconfigured path value for the cookie. I've attached screenshots of 2 requests in Firefox and Opera.
As you can see in the screens, FF sees the cookie headers and sets them appropriately, but Opera does not.
Firefox Request
Opera request 1 Screen
Opera Request 2 Screen
I haven't included the code from the proxy that does the request forwarding, so please let me know if you need that to gain some insight. On the service end, I'm running PHP and Codeigniter. Please let me know if I need to add any more info here on my environment, thanks.
UPDATE : This issue occurs even in my production environment which does not use a custom TLD. Other sites that use cookies work fine and cookies are enabled.
Double quotes are formally illegal in a cookie value. If you escape them as %22 it will work.
Have you checked if this is an issue with cookie domains ? I'm assuming you're using Javascript to set/read the cookies ? In any case there are 4 cookie domain issues that you might want to check (I know I've had these issue with an old FF version):
1 - check for illegal cookie characters: allowed cookie characters you might not be allowed to use '-' or '=' in the cookie name, and you shouldn't use non-ASCII characters in cookies at all. A base64 encode might deal with this.
2 - check that the domain on which you set your cookie (via javascript code or any other way) is identical to the domain on which the code is executed.
3 - check that the cookie domain is not localhost; see if you can test setting the cookie from a remote domain
4 - if you're using JS to set your cookies, try testing if you can set the cookie with a CGI in your browser to make sure it's not a browser issue. If it works which it should, see if you can read the cookie using JS (as opposed to setting it).
Let me know how this goes in the comments, I've dealt with similar issues a number of times and depending on what you get with these checks, I'm pretty sure I can help you fix the issue.
Have you checked the "leading dot" form of a cookie domain in setcookie. I've been using leading dots for years and only recently noticed my app wont set cookies on opera (chromium et al?) due to the leading dot which is part of a deprecated RFC. In opera, it's not that the leading dot gets ignored but the very setting of the cookie itself. I've removed the leading dot and its working now.
Looking at those Opera screenshots, they seem to be AJAX / XHR requests which are processed within the same second. Is it possible that Javascript is triggering both of those requests "simultaneously", so the response from the "first" is not arriving before the request for the "second" is constructed - and therefore the cookies have not yet been set?
I'm not familiar with the technologies/toolkits you're using, so don't know if these are stock code or part of your custom application.
In my Zend Application, I am trying to make our authenticated users be automatically logged out when they close their browser.
For that I'd write following code:
ini_set('session.cookie_lifetime', 0);
And its working fine on browsers like Chrome, Safari, IE7 and IE8, but in case of firefox, users still remain logged on when they close their browser.
Does anyone know what is causing problem?
Thanks In advance...
A value of 0 indicates "session cookie" - i.e. one that the browser should destroy when the "session" is over and the browser is closed.
However:
Different browsers have different interpretations of exactly what a "session" is - some will destroy these cookies when your close the tab, some when you close the window, some won't destroy the cookies until all instances of the browser have been closed - all tabs in all windows.
Since cookies are stored and transmitted by the client, they are completely the responsibility of the client. You should not rely on cookies alone to control whether a user has a valid login because they are ridiculously easy to spoof, you should implement some kind of activity timeout as well.
Make sure you have actually ended your Firefox session when testing - close all open tabs and windows, and watch the process list to ensure there are no instances left. If you are still having a problem, you are probably looking at some kind of bug in Firefox (or maybe you've made some strange change in about:config) and you need to ask for Firefox-specific help - SuperUser.com would be a better place for that. One thing you can be fairly sure of is that if it works everywhere else, it's not a problem with your PHP.
I have a PHP site that makes use of sessions, which obviously are not supposed to be able to persist if you close your browser. I've done this scores of times, no issues.
And no issue currently - except within Microsoft's new Edge browser. If the user logs in, works in the site, closes Edge's window in the top right corner, and then re-opens the page and pastes the web address (or bookmarked it before), all their variables from the previous visit are still present. That's a problem, as each visit the viewer will likely want to give/lookup changing information.
I've successfully replicated the problem in Edge. What I can't figure out is why Edge is doing it. Every other browser kills the session and all its variables upon closing of the window (tested all the major browsers, including Internet Explorer). The only thing I can think of is Edge isn't actually closing as a program when the window is closing. Has anyone else ran into this problem? I can't find anything in the forums.
It is possible the session ended, but there is a bug with the cache.
I noticed that Edge is very aggressive with using cached pages. It would show a signed in page even after the user signed off (actually killing their session and updating the session cookie) because it would not respect the etag or any other cache instructions. I had to specifically prevent IE11 and Edge from caching at all.