I'm developing a Rails 3 app on Ubuntu 10.10 and need to check the CSS and Javascript on IE7 and IE8, so I'm using VirtualBox and the images that Microsoft provides. I've gotten the images installed and running well - I can use IE7 and IE8 to access the internet and use sites just fine.
I can also access my development Rails app (running on Ubuntu) by visiting 10.0.2.2:3000 in each browser (not sure why that works and localhost doesn't, but oh well). Any GET on a page that doesn't require the user to be logged in renders as I'd expect it to.
What's wrong are the sessions - as near as I can tell, both IE7 and IE8 are both just completely ignoring sessions with the development app. Whenever I submit the login form I get an InvalidAuthenticityToken error, and sure enough, in Rails' error page, the values in the session and params don't match. I even set up a special route to automatically log in the visitor as a random user, but it doesn't work. I just downloaded and installed Firefox in one of the virtual PCs and it's having the same problem as the IEs are.
Everything works perfectly in Chrome/Firefox in Ubuntu, so it doesn't seem to be Rails, and apparently it's not IE. I suppose there's something I'm missing with VirtualBox, but I have zero experience with virtualization before today, so I don't even know how to begin troubleshooting it.
Any advice?
Figured it out: The cookie wasn't being set because I was visiting the app through the ip address (Rails' :domain => :all option for the cookie store apparently doesn't cover that eventuality). I pointed lvh.me to 10.0.2.2 in the hosts file in WinXP, and everything works great.
I just had a similar problem on IE8, session cookies were turned off. My Rails app login worked after I turned session cookies to on via:
Internet Explorer > Tools > Internet Options > Privacy tab > Advanced button > tick "Always allow session cookies"
Related
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'm running Firefox 36.0.4 on Windows 7 32-bit. I've diabled all add-ons, extensions and user scripts before retesting this.
I'd like to step through JavaScript code that is served up in a <script> tag in the HTML document being produced by a Java (Tomcat) web server.
Unfortunately, when I select the HTML document under Debugger > Sources, the source of the page returns to the login page of the application - it appears that session information is not being used to request the source.
I stepped through the server-side code and found that the correct session cookie values were being sent for the real page request and some AJAX requests sent by the page. However, when I tried to load the page source in the JavaScript debugger, I found that an incorrect session cookie was being sent by the JavaScript debugger.
I can replicate this behaviour in other webapps, not just my own. For example, Stack Overflow:
Is this a configuration issue, or a bug in the Firefox Developer Tools?
I can't reproduce your problem using StackOverflow as an example, at least in Firefox Developer Edition ( currently version 38 ):
One thing that might help - try disabling the cache while the toolbox is open - this setting is in the developer tools setting panel ( click on the 'gear' icon at the top right of the toolbox ):
After reviewing canuckistani's answer, I downloaded Firefox Developer Edition. Seemingly, the problem was fixed.
Five minutes in, I became sick of being asked whether to remember passwords and having to manually clear session cookies (I prefer being able to do it by simply closing the browser) - it makes testing easier.
As per usual, I went to Options > Privacy > History to disable this behaviour, by setting the value to Never remember history.
Changing this setting requires the browser to restart. However, upon restarting, I once again saw the same erroneous behaviour - the wrong session cookie was being sent to the web application again.
The workaround here is to not use the Never remember history setting. I have filed a bug report at Mozilla.org Bugzilla.
I have an existing website and suddenly some days ago I can't use Google Chrome anymore for developing. When I use a standard edit and create page, I get the above error. But i'm not getting it in Internet Explorer. I use Windows 10 (all updates installed) and VS2013 with Update 4. The project is the latest MVC version. I even checked the web.config but nothing is changed. I deleted all history, cookies, passwords etc.
Anyone any idea?
I had the same problem. For me the solution was to both clear my browser cookies and to disable Adblock. Other addons may have the same effect. I believe the problem is limited to the Visual Studio / Chrome development environment and will not occur in production regardless of whether the end user has Adblock enabled or not.
Do you have a
<httpCookies requireSSL="true" />
in your Web.config? Change that to false. Then in your transforms files (Web.Prod.config, and other environments that have SSL):
<httpCookies requireSSL="true" xdt:Transform="SetAttributes" />
I'm also having the same issue in recent weeks, but it's also extending cross-browser after originating from Chrome. What's even stranger is that it still works flawlessly with the identical project on a different machine using all browsers.
I have gone so far as to uninstall all extensions, delete all cookies / data, sign out of Chrome completely and re-install it. Problem still persists.
On deployment to Azure websites the problem isn't present on any platform. My current work-around is to Ctrl-F [ValidateAntiForgeryToken] and comment out every occurrence, and re-enable it upon deployment. Annoying, but it works.
This was happening to me in Chrome, and seemed related to using the 'remember me' checkbox on login forms, and closing then re-opening the browser. The token was present on inspecting page source, but was reported as being not present during debugging sessions in visual studio. By clearing the browser cache and not checking the 'remember me' box I did not get the problem - but I don't fully understand why!!
My steps to reproduce the bug in Chrome:
Sign in to your MVC web application, clicking on 'remember me' to make it checked
Close browser
Open browser to your current retained session
Try to sign out - error happens here.
Anyway, the following solution worked for me. Inside your MVC view form, try replacing this:
#Html.AntiForgeryToken()
with:
ViewContext.Writer.Write(Html.AntiForgeryToken().ToHtmlString());
Are you on cloud platform ? chrome emits cookies from cloud domains hence the only way to do it is to map another named domain to your cloud web site
This is probably because browsers like Chrome use the Public Suffix List(https://publicsuffix.org/list/effective_tld_names.dat) to restrict certain cookies. If the domain suffix set on the cookie is shared publicly then the browser may block such a cookie in order to prevent itself from sending "unauthorized" data to other servers running on the same domain.
I have a fairly vanilla Rails application on heroku that works fine ... except on my Dad's computer. It is Windows 7, and the site always shows as a blank page. I have checked the following:
Both Chrome, Firefox and IE (latest versions) all exhibit the problem. Web inspector on Chrome and FF shows either a 200 or 304 response code, but blank body.
I have tried clearing the cache.
Curl on his machine successfully downloads the page.
My laptop on his network views the page fine.
His laptop on other networks still exhibits the problem.
His other laptop works fine.
Multiple other machines (5+) work fine.
Server logs show a successful response being served.
Turned off Microsoft Security Essentials.
Turned off the firewall.
I'm stumped. What other debugging steps should I try?
For reference, the site is http://gccc.herokuapp.com/
Solution from twitter: https://www.malwarebytes.org/ picked up a couple of Trojans that were causing issues. I had assumed "Microsoft Security Essentials" was doing this, but I guess that is something different.
I am writing a web application, and http://localhost:3000 is redirecting to https://localhost:3000
This was not happening a month ago when I finished writing two other applications. I went from working with Sinatra to Rails in the past month, although I have worked with Rails prior without any of these issues.
What can I do to stop this forced switching??
This is probably due your browser, because you have accessed the app in the HTTPS address, it will automatically switch to the HTTPS version of site.
Here you have more information for Firefox, but the solution is to change the settings and set browser.urlbar.autoFill to false. Other option could be to clear the History.