I'm using a rails application to serve a page from abc.com. In it, I set the response headers in my application controller (for every request through before_filter) so that it can be accessed through an iframe only from a specific site (xyz.com), through the following code:
def set_x_frame_options
response.headers["X-Frame-Options"] = "ALLOW-FROM http://www.xyz.com"
end
The problem is, not only am I able to access the page from abc.com on xyz but also on any other website. I want to limit the access to only xyz.com. When I examine the response headers in chrome console I can see the X-Frame-Options is being passed on correctly. This is happening across all browsers. Am I missing something?
For those looking for a definitive answer: it's not implemented in webkit, but does work in Firefox reportedly as of version 18.0. The following ruby syntax works for me in Firefox 20.0 on OSX:
response.headers["X-Frame-Options"] = "Allow-From http://www.website.com"
Related
Hello everyone (sorry for bad English), i'm getting crazy with this problem... i'm working on a project with NiFi expecting to download PDF files from a public Goverment page. The main problem it's that the page you request in a web browser shows the correct page like this
Asking the same page in NiFi (also testing in postman) shows that the session has expire, then looking at the HTTPS POST with the development tools in chrome i notice that there are multiple headers that contain dynamic variables
Is there any form to replicate web browser behaviour on NiFi?
I have a Rails 6.1 app that uses sessions to store some data.
When I open the app in an iFrame the sessions do not work (I cannot get their value when navigating to another page of the app, still inside the same iFrame)
I read a lot about this and played around with the cookies same_site configurations etc.
I also read about Chrome being the reason but I tried it in Safari with the same issue.
But I do not want to share sessions between the rails app and the page that contains the iFrame. I just want that the app works normally inside the iFrame.
Any ideas what could be the reason?
In order for your session cookie to work inside of an iframe, you need to explicitly set its SameSite setting to None.
Rails version ≥ 6.1
Rails 6.1 introduced a new configuration option, which you can set e.g. in your config/application.rb:
config.action_dispatch.cookies_same_site_protection = :none
The relevant section on the guides is here.
Rails version < 6.1
Your best bet is most likely to use the rails_same_site_cookie gem.
Secure setting
When setting SameSite to None, you must also ensure that your cookies are sent with the Secure setting set to true. This happens when you uncomment the following line in config/environments/production.rb:
config.force_ssl = true
Where is this change from?
The relevant commit for Rails 6.1 is here. It boils down to Rails now explicitly setting SameSite=Lax on every cookie it sends.
Testing
I have found that the best way to locally test a setup such as this one is to run a separate server (e.g. a Middleman instance) to simulate the third party page which embeds your Rails app in an iframe.
Then you can point one browser tab to localhost:3000/my/iframed/page, and the other to lvh.me:4567/my/embedding/page. You should be able to sign in one tab and act as the signed in user in the other.
It is crucial to also test this in a production-like environment.
None vs Lax vs Strict
If you were to set SameSite=Lax, this setup would only work when both tabs are pointing to the same domain, e.g. localhost. With SameSite=Strict, it would not work at all.
When you are testing this, if you switch from e.g. :lax back to :none, you will be logged out from both tabs.
Response headers
Note that changing SameSite's value is not enough to set up your Rails app to work inside of an iframe. You also need to set the right headers in the relevant controller action, like so:
response.set_header("X-Frame-Options", "ALLOW-FROM #{embedding_url}")
response.set_header("Content-Security-Policy", "frame-ancestors 'self' #{embedding_url}")
Where embedding_url can be *, if you'd like anyone to be able to embed your Rails app via an iframe.
For further reading, the nice people over at makandra have compiled a card specifically about the SameSite setting.
Safari support
There is nothing you can do to fix the problem in Safari—besides asking your users to uncheck the Prevent cross-site tracking checkbox in their preferences. In the future, the same is likely to apply to all major browsers (see here for the relevant Chrome blog post).
I am running Apache 2.4.18 on Ubuntu (single server machine). I didn't make any changes to the default settings as far as cache headers are concerned (no cache-related change to /etc/apache2/apached2.conf, no .htaccess files). My understanding is that apache's default behavior is to use ETag's, with the desired behavior of returning a 304 if the client already has a matching file, or a 200 (plus the new file) if it does not.
This is not what I see.
On iOS/Safari, when I update files on the server, my client behaves as if it has a mix of old and new files. This can be resolved by clearing web data in Safari and reloading the page, so it does seem to be a caching issue. I read that iOS/Safari is (or at least was, in earlier versions?) different in its respect for ETag headers. But it wasn't clear to me how to fix this.
On Chrome in Windows, the file is always served (i.e., response 200, not 304) even when the file hasn't changed since the last request, even though I can see the use of ETag in the headers.
Can someone share their apache 2.4 settings to get the desired behavior I describe above, on both iOS and Chrome?
(Here is another question that asks the same thing about the Chrome part: Apache + Etags -> returns 200 and send content instead of 304)
I think the answer to my question is that caching works differently, at least in Chrome, when you are using the file:// protocol to test locally vs. the http:// protocol.
I'm running Rails 3.1.2 on Apache with the latest Passenger, 3.0.11. I'm using force_ssl to require a secure connection in a few of my application's actions.
The web browser is warning that although the identity of the site has been verified and the connection is encrypted, the page contains other resources which are not secure. The culprit is a reference to the Google Fonts API being made over plain http. My view contains the following:
= stylesheet_link_tag "#{request.port}fonts.googleapis.com/css?family=Oswald"
I also tried this:
= stylesheet_link_tag "http#{request.ssl? ? 's' : ''}://fonts.googleapis.com/css?family=Oswald"
Both of these result in the stylesheet url having "http://".
I had success doing this in a Rails 3.0.5/Passenger 3.0.7/SslRequirement, but can't get it to work in Rails 3.2.1/Passenger 3.0.11/force_ssl.
put "//fonts.googleapis.com/css?family=Oswald" without the http or https - that way the browser uses the same protocol as the page you are on and doesn't show any warnings.
I am using
Response.Redirect("someurl",true);
in the page_preInit event to redirect all the requests that come to a page. It works fine on Firexox, but if i access the page from internet explorer 7/8, it says page can not be found and will not redirect to new URL.
Any idea why this happens??
Update:
I tried giving a radom URL in the redirect such as google.com and it works fine. Actually the URL I am trying to redirect is not accessible on my machine, it is on another VPN. I guess IE will not change the URL on the addressbar if it can not access the URL. Firefox on the other hand changes the address on the address bar.
Is your Response.Redirect contained within a try/catch block? This can cause issues with Redirection.
As i mentioned on the Update, IE wont change the URL if it returns 404. Since i had no access to the URL i am redirecting, it was returning a 404. But firefox behaves differently.
I also had a similar issue where Internet Explorer would not redirect using a standard Response.Redirect call. I also saw the same issue on certain Android devices on WIFI, but who worked correctly on cell service. Very strange.
The problem is with Microsoft's legacy redirect method in .NET. Certain network routers and older browsers handle the response codes differently. Here's the change to C# code that fixed it:
OLD CODE:
HttpContext.Current.Response.Redirect("www.mysite.com", true);
NEW CODE:
WebOperationContext.Current.OutgoingResponse.StatusCode = System.Net.HttpStatusCode.Redirect;
WebOperationContext.Current.OutgoingResponse.Headers.Add("Location", "www.mysite.com");