This is for Safari 5.1.4 and 5.1.5 only. It works on older Safari versions.
if you go to:
http://gemal.dk/test/restob.html
and click on the button you get a Online Booking inside a iframe
If you the click on a green day and then a time you are presented with a "Your session has expired".
If you check the cookies you dont have any cookies.
Safari is rejecting the session cookies and this started around the Safari/Google issue where Safari became more strict about 3rd party cookies. Version 5.1.4+
How can I solve this? How can I set the cookies in the iframe?
I send the correct P3P headers. I've tried a lot of things I just cant get it working.
It works in all other browsers than Safari 5.1.4+
Maybe ,The following link would be helpful to you .
http://www.reizbombardement.de/archives/safari-5-1-4-enforces-cookie-policy
Safari 3rd party cookie iframe trick no longer working?
Certainly, To set a cookie for your domain and refresh the opener and then closes,
you must prepare dummy page(ex...safari_cookie_fix.php)
But...
In Our project , We prepare its dummy page as Good-looking(Not bad usability!) loading page.
I experimented a similar problem.
A web "parent" page open my "child" website in a jquery fancybox i-frame cross-domain.
Not problem at all with Explorer, Chrome, Firefox, Opera and even with Safari (5.8.1) on MAC.
But with iPhone, iPad and mini iPad, the session in the i-frame is lost.
That's mean that at every click on an element in the i-frame (web site is in aspx) a new session started.
We solve the problem in a very simple way:
when the parent website start, it call a page in the child site directly (not in an i-frame). In this page I just set a session variable and I redirect to the parent website.
Now when the child website is open in an iframe, the session is kept.
Related
Here's my problem
I have a website(X1.com) which contains a login and a button(window.open) after login to open another app (X2.com) in a detached window.
this X2.com has list of items and when I double click an item it is supposed to open X1.com/item1.
All of this was working as expected when I was using IE9, chrome and firefox.
But when updated my IE9 to IE11 double clicking the item on X2.com is taking to the login page of X1.com saying session timed out. Chrome still works fine. When I close/logout and login again to X1.com keeping X2.com window open X2.com is able to open that X1.com/item1 page properly.
Is there an internet option or security setting or a plugin in IE that's blocking X2.com from opening X1.com/item1 page first time?
My company uses IE11 only for operations and that's why I have to get it working. Please ask if my question is not clear. I can provide the exact urls if required.
It's a common issue in IE11, as a workaround add registry entry of value 0 at:
HKEY_CURRENT_USER/Software/Microsoft/Internet Explorer/Main/TabProcGrowth
In our application we have some elements that work with ajax.
We offer users to embed parts of the app in an iframe.
Everything work fine in Chrome and Mozilla. In Safari we get 422 error, and the server log looks like this:
2015-07-15T08:26:06.818885+00:00 app[web.1]: Completed 422 Unprocessable Entity in 4ms
2015-07-15T08:26:06.815411+00:00 app[web.1]: Can't verify CSRF token authenticity
2015-07-15T08:26:06.823389+00:00 app[web.1]: ActionController::InvalidAuthenticityToken (ActionController::InvalidAuthenticityToken):
We figured out that if we access directly the iframe url AND THEN to the page which contains the iframe it works fine, which might indicates that it has to do with cookies.
I tried this solution, but we still have this problem.
Safari does not (by default) allow cookies to be set in iFrames unless the user has visited the site already. Imagine this code:
# a.com
<iframe src="b.com/iframe">
If you visit b.com directly (any page) and it sets a cookie, then Safari will send that cookie when you visit a.com and the iFrame to b.com is loaded.
However, if you visit a.com without first visiting b.com, then Safari will ignore any cookie that b.com/iframe tries to set.
The solution is described here (if the link doesn't work for you, here is version saved by web archive) in the section called "A solution for Safari".
Detect if cookies are supported.
If not, put an overlay on the page saying, "This site requires cookies. Please click here to continue."
When the user clicks on the link/button, open a popup, which sets a cookie and closes itself. On desktops you can make the popup fairly small and innocuous. On mobile devices it is uglier since you can't make the popup smaller than full-screen. However, either way the popup is only on screen for less than a second.
The iframe reloads itself and it can now use cookies.
Finally I figured out that Safari does not allow keeping cookies in iframe.
It means that if you need to use cookies, you need to do something.
The solution I found is this:
In the iframe code check if session[:safari_cookie_fixed] exist. If not, render a code that will communicate using postMessage with the parent window and let him know that we need a redirection.
The parent window send a signal via postMessage to the iframe when the iframe is loaded. The listener, which was rendered in case the cookie does not exist, send a signal to the parent to perform redirect, and the parent does a redirection to /set-cookie page in the iframe domain, adding its current url as a query-string parameter.
set_cookie action save a cookie safari_cookie_fixed and redirect back to the parent page (which its url is available in the query-string)
Of-course this solution requires adding some js code in the parent page, but when you give your user the iframe html code you can include the js as well.
I saw this question asked here 18 months ago, but without (a correct) answer: Window like facebook chat
Both Facebook and OkCupid have messaging windows which stay open even when you click to another page on their website. Literally the IM window (and friend list, on Facebook) don't so much as flash or "blink" as if they were reloading quickly. If you refresh the website (F5 or such) then the messages will disappear, at least for a moment.
The only thing I can think of is that the entire website never actually changes addresses, but just pushes the new URLs to your browser so it looks like the URL changed, but you never really left the same file.
How are they offering this persistent chat?
My guess is they are using something similar to qjuery-pjax:
https://github.com/defunkt/jquery-pjax
From their docs:
pjax works by grabbing html from your server via ajax and replacing the content of a container on your page with the ajax'd html. It then updates the browser's current url using pushState without reloading your page's layout or any resources (js, css), giving the appearance of a fast, full page load. But really it's just ajax and pushState.
This means clicking a link on the page will load only part for page and leave the chat windows untouched (no flicker). If you hit F5, the browser is initiating the refresh which will not use ajax/pushState. This causes the chat windows to flicker.
I'm using PHP(header) to send a user back to the home page of the website(which looks different, due to a cookie, then when the user first arrived).
Everything works fine in Google Chrome but in Safari and FireFox a cached version of index.php is shown instead of the updated version of the webpage.
If I hit refresh things look as they should, but I need a way to tell the browser to reload the page without the user having to hit refresh.
Try this...
http://smartcoding.wordpress.com/2009/01/28/php-force-no-cache-page-load/
I have a number of sites using Kohana's session handler set to use database sessions. Everything works fine until I turn on Resource Tracking in Safari's Web Inspector. After enabling resource tracking, the page refreshes (normal), but then if I refresh the page twice I get logged out. From what I can tell, the session id/key changes therefore it has no session. Upon watching the storage/cookies area, I can see the session id cookie change immediately.
I haven't been able to reproduce similar behaviour in any other browser, including Chrome (Webkit).
Any ideas what might be causing this?
This appears to be fixed in Safari 5.1, so in other words, no longer an issue. Still love to know why it was happening (in case there's another issue), but for now it's resolved.