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.
Related
If you carefully notice facebook, you will understand that the when you visit one page to another then the whole page is not refreshed or redirected but the URL changes when navigating to new page. It is more clear when chat windows are open, they remains static during page loading. As other website does this by using the # but facebook does not.
There is another example came to me: http://www.davidwalsh.name/. Visit the site and open other pages within their site and you will understand what I mean. Don't forget to notice the URL change.
How they do this?
Added More: I want a way that the page content will be loaded with ajax, change the URL for bookmark feature but when changing URL it should not reload / refresh the page by not using # (hash).
You have two questions:
For the URL change you can put the path instead of the # in the href property of the anchor (e.g /otherlink).
For opening the chat or opening some div does not require to send it in the url, its the onclick event on the div and its expands. Also the chat remains open may be thay set cookie or flag when the chat is first time opened and checking and changing the chat with flag they are setting.
As suggested by #andytuba
For Facebook, Google "hash navigation ajax".
For DavidWalsh, google "history API".
I am just wondering how facebook manage requests to "my profile page" and "home page" and some other pages that seem to reload just some content.
For example when I am on "my profile page" on facebook, i Hit the home button and the top bar button and chat panel on right side remain intact (they are not reloaded). I have monitored XMLHTTPRequest in webkit console and no ajax is generated, so its not Ajax (i think). Otherwise, if FULL http requests are generated when clicking those links, I thought the full page must be reloaded, I am right? So I have no clue how is this handled. Can you give me a hand please?
Thanks :)
It's a type of performance optimization called "quickling", they also use a "pagecache" strategy to reduce the data from server. In the lower level, it depends on javascript perform as a LinkController, which delegate a hyper-link click event and then send an ajax (or use iframe) to request the pagelet data from server, the response will be a json-formed data structure, then javascript will insert the content of current page. Uri in your address bar can be dealled with the hash change event in old browsers and H5's History API (pushState) to manage the history record of browser.
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.
I have a page that gathers environment status from a couple of IBM WebSphere servers using iframes similar to this:
<iframe src="http://server:9060/ibm/console/status?text=true&type=server&node=NODE&name=ServerName_server_NODE"></iframe>
and it happily prints out "Started" or "Unavailable" etc. But if I load the same url in a normal browser sometimes it works, sometimes it does not? Some of them are showing a login page, while others are simply return HTTP code 500.
So whats the difference between loading the page through an iframe vs through a browser?
I can tell you that the iframe solution works no matter which machine I am doing it on, so I do not belive it has anything to do with the user whos opening the page. And before you ask, why not keep the solution that works, well its because it takes a long time to open the page with the iframes vs a page where everything is requested through ajax.
Update: Using jQuery to perform the ajax call returns "error" and "undefined" for the servers that I can't see in a normal browser.
One difference is an iframe has to render the view while XHR would not.
An iframe is essentially the same as opening with the browser. In both cases the browsers credentials are used, so there will be no difference between the two.
Secondly, loading something in an iframe should take the same amount of time as requesting it through XHR, since in both cases the browser makes an HTTP request and waits for the response. Although I should add that an iframe will take time to render the content onto the page. However if you plan on displaying it with ajax anyways, an iframe/xhr solution will be more or less the same.
In case of ajax request same origin policy (which restricts cross domain call) comes into picture. So you can't make cross domain call using xhr. Alternative for same is embed flex swf file in your page as activex control and make flex call through javascript and then flex is responsible to make cross domain call (flex can if targeted domain allows cross domain using crossdomain.xml) and renders result using javascript again.
Greetings,
Here's the problem I'm having. I have a page which redirects directly to another page the first time it is visited. If the user clicks 'back', though, the page behaves differently and instead displays content (tracking session IDs to make sure this is the second time the page has been loaded). To do this, I tell the user's browser to disable caching for the relevant page.
This works well in IE7, but Firefox 3 won't let me click 'back' to a page that resulted in a redirect. I assume it does this to prevent the typical back-->redirect again loop that frustrates so many users. Any ideas for how I may override this behavior?
Alexey
EDIT: The page which we redirect to is an external site over which we have no control. Server-side redirects won't work because this wouldn't generate a 'back' button for in the browser.
To quote:
Some people in the thread are talking about server-side redirect, and redirect headers (same thing)... keep in mind that we need client-side redirection which can be done in two ways:
a) A META header - Not recommended, and has some problems
b) Javascript, which can be done in at least three ways ("location", "location.href" and "location.replace()")
The server side redirect won't and shouldn't activate the back button, and can't display the typical "You'll be redirected now" page... so it's no good (it's what we're doing at the moment, actually.. where you're immediately redirected to the "lucky" page).
I think the Mozilla team takes a step into the right direction by breaking this particularly annoying pattern. Finding a way around it somehow defies the purpose, doesn't it?
Instead of redirecting on first encounter, you could simply make your page render differently when a user hits it the first time. Should be easy enough on the server side, since you already have the code that is able to make that distinction.
You can get around this by creating an iframe and saving the state of the page in a form field in the iframe before doing the redirect. All browsers save the form fields of an iframe.
This page has a really good description of how to get it working. This is the same technique google maps uses when you click on map search results.
I'm strongly in favor for the Firefox behaviour.
The most basic way to redirect is to let the server send HTTP status code 302 + Location header back to the client. This way the client (typically a browser) will not place the request URI into its history, but just resend the same request to the advocated URI.
Now it seems that Firefox started to apply the bevaviour also for server responses that try redirections e.g. by Javascript's onload event.
If you want the browser not to display a page, I think the best solution is if the server does not send the page in the first place.
Its possibly in aide to eliminate repeated actions.
A lot of ways people do things is
page 1 -> [Action] -> page 2 -> redirect to page 2 without the action parameters.
Now if you were permitted to click the back button in this situation and visit the page without the redirect, the action would be blindly re-performed.
Instead, firefox presumes the server sent a redirect header for a good reason.
Although it is noted, that you can however have content delivered after the redirect header, sending a redirect header ( at least in php ) doesn't terminate execution, so in theory, if you were to ingnore the redirect request you would get the page doing weird stuff.
( I circumvent this by the fact all our redirects are done via the same function call, where i call an explicit terminate directly after the redirect, because people when coding assume this is how it behaves )
In the URL window of firefox type about:config
Change this setting in firefox
browser.sessionstore.postdata
Change from a 0 to 1