My sites when used in iframes stop working in Safari browsers because session variables stop working, in IE or Chrome they still work.
To resolve this issue, you had to configure IIS as follows:
If you have ajax calls, remove the back slash from url "\Compra"
Related
I'm having an unending issue trying to use the AppEngine API explorer with the stupidly simple helloworld example.
When trying to navigate to the url to explore the API my Chrome browser redirects to HTTPS from the default HTTP and no API's are listed. I have gone through every possible fix I can find (Like this, and all of these) and none are working reliably.
What's the most infuriating is I have gotten the API listed TWICE but now no longer displays with any of the methods below.
The setup I had when it worked the first time:
Chrome launched with "C:\Program Files (x86)\Google\Chrome\Application\Chrome.exe" --unsafely-treat-insecure-origin-as-secure=http://localhost:8080 (As per the tutorial)
The url being: (http://)apis-explorer.appspot.com/apis-explorer/?base=http://localhost:8080/_ah/api&root=http://localhost:8080/_ah/api#p/
The second time it worked was using also using the above URL but lasted only a second before being redirected to HTTPS and not listing anything.
Some specifics:
Windows 10 OS.
Every time the page loads I get the "The API you are exploring is hosted over HTTP, which can cause problems. Learn how to use Explorer with a local HTTP API." message, even the times the API displayed correctly.
Every time I now load any of the API Explorer URLs I get redirected to HTTPS, and nothing is listed. Also the URL is escaped (%3A instead of ':'). Not sure if it's important but the first time it worked the URL was HTTP and NOT escaped.
I have tried the shield in the search bar and enabling Load unsafe scripts ( from here).
Tried launching Chrome as usual and with the flags --unsafely-treat-insecure-origin-as-secure=http://localhost:8080 and/or --allow-running-insecure-content (from this answer).
Tried http://localhost:8080/_ah/api/explorer
Tried http://apis-explorer.appspot.com/apis-explorer/?base=http://localhost:8080/_ah/api#p/
http://localhost:8080/_ah/admin works correctly and shows the Admin console every time.
Since the API's being listed once I haven't touched the project code, but restarted the server, Chrome, and tried different URLs on more occasions than I care to count.
I also tried accessing the API URL directly as explained in this answer but cannot find the correct URL to access the helloworld /sayHi endpoint. Maybe someone can help me work out what I need to prefix it with as all of the variations I try give me a 404.
Any help would be a very very appreciated.
I'm writing an app for Facebook, which needs to be secure. The initial page, https://myapp.com, loads perfectly fine.
However when I click a link to https://myapp.com/link, Chrome complains that the app is trying to load from an insecure source. I get the following message in the console:
"[blocked] The page at 'https://www.facebook.com/page/app_###' was loaded over HTTPS, but ran insecure content from 'http://myapp.com/link/': this content should also be loaded over HTTPS."
Now the link is an absolute URL with the https prefix, yet apparently the page is trying to load from the http version.
I visited the domain itself and checked the Network tab in the Chrome console to see what was happening. The following happens:
The GET to https://myapp.com/link is a 301, moved permanently.
This then redirects to http://myapp.com/link
As far as I can tell, there is nothing in my python code to make this happen, so I suspect some feature of Heroku is causing this, but I haven't been able to find anyone else with this problem.
As a side note, I used Flask-SSLify to add a redirect back to the https version. This redirect works, but Chrome still blocks the page because it passes through the insecure version.
I feel so stupid for working this out five minutes after posting the question, but it is a little obscure.
It turns out the problem was that the page I was attempting to reach was "https://myapp.com/link/" with the trailing slash.
"https://myapp.com/link" redirects to "http://myapp.com/link/".
I don't know why the protocol isn't preserved by this redirect, it may be either Flask or Heroku, though I suspect it is Flask. Regardless it seems like a bug.
Hope this winds up helping somebody else.
I am developing a Rails application that uses SSL connection. I am currently using third party resources that are js and css files for implementing a map (OpenStreetMap) . I have already tried to import these resources (js and css) into my application, but the javascript code tries to access an external WMS via HTTP.
The problem is that Google Chrome is blocking access to third-party resources from HTTP when the application is in HTTPS.
So I disabled SSL on a certain pages of the application and tried to force the HTTP or HTTPS the way I desire.
Following this blog: http://www.simonecarletti.com/blog/2011/05/configuring-rails-3-https-ssl/ and it works.
But when I force the HTTP protocol to the page where these resources will be used using Google Chrome, it forces HTTPS connection causing infinite loop.
If I clear the Chrome cache (that have already accessed the same page with HTTPS) in order access it via HTTP it works. But if I have accessed a HTTPS page and try to access via HTTP, Chrome forces the HTTPS connection resulting in an infinite loop.
The question is: Is there something I can set in the request that causes Chrome to accept the connection?
Regards
I've been doing some research on this, and it turns out that turning on force_ssl = true on Rails 3 causes the app to send an HSTS header. There's a bit of information about it here: How to disable HTTP Strict Transport Security?
Essentially, the HSTS header tells Chrome (and Firefox) to access your site only through HTTPS for a specific amount of time.
So... the answer I have for you now is that you can clear your own HSTS setting by going to about:net-internals within your Chrome browser and removing the HSTS state.
I think the answers here can help you: Rails: activating SSL support gets Chrome confused
I'm loading Disqus on a page loaded via HTTPS with the following code, as suggested in this answer.
<div id="disqus_thread"></div>
<script type="text/javascript">
var disqus_shortname = 'our-shortname';
(function() {
var dsq = document.createElement('script'); dsq.type = 'text/javascript'; dsq.async = true;
dsq.src = 'https://' + disqus_shortname + '.disqus.com/embed.js?https';
(document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(dsq);
})();
</script>
Note that I've changed the request of embed.js to be https rather than http, and I've added ?https to the end of the request too, which I believe is supposed to force HTTPS.
The initial request goes via HTTPS as planned, but it makes a secondary request via HTTP, which Chrome is hating (I get the red cross over padlock icon).
From the Chrome console:
The page at https://our-website.com/blog-post-name ran insecure content from http://juggler.services.disqus.com/event.js?thread=635675380&forum=our-shortname...[long query string]
Is this the correct method to get Disqus to use ssl on all requests, or have I missed a step?
Thanks.
This looks to be an issue within Disqus itself. We had Disqus working fine via SSL with the same approach in a couple of Drupal sites, but both recently had Disqus begin causing SSL warnings in both IE and Chrome as you've described.
I did a bit of digging, and I see that the DISQUS.useSSL function that's defined in embed.js and called in thread.js updates a few URLS (specifically ["disqus_url","realtime_url","uploads_url"]) in the Disqus json settings object by replacing http in their URL with https if https is found in the settings. The juggler_url doesn't get the same treatment, and so it's not updated to load via SSL. I'm not sure what juggler's purpose is, but it appears that that URL (http://juggler.services.disqus.com/) won't load via SSL in any case, so even if it's url was changed to https, it still wouldn't work.
So perhaps Disqus has made a recent change, since we had this working previously? We're taking this up with them, since this doesn't appear to be a config issue on our end...
UPDATE:
Apaprently Disqus launched a new service that does not support SSL. This is what's generating the extra scripts that get loaded insecurely, thus triggering the security warning. Disqus disabled this new service (which they didn't tell us the name of) for our specific account, and now SSL is once again working as expected. So, the solution is to just ask them to make your account SSL compliant, and that should take care of it.
Found this article, which hands the solution:
http://help.disqus.com/customer/portal/articles/542119-can-disqus-be-loaded-via-https-
Basically it's not possible (yet) with Disquss 2012, but switch it off and change the embed src so it uses https:// and add the ?https param:
dsq.src = 'https://' + disqus_shortname + '.disqus.com/embed.js?https';
I have had this problem off and on for the past few months and have been forced to disable Disqus altogether. Initially I contacted Disqus to see if they could make the switch that disabled the non-SSl compliant feature on their side and this worked for a while but the mixed content problem kept re-occuring.
What seems to happen is that despite Disqus forcing the https version of its count.js javascript, count.js still redirects to mediacdn.disqus.com instead of securecdn.disqus.com for some reason. If one appends ?https manually in the plugin editor to force the redirect to the securecdn.disqus.com, the problem disappears in the first call to the CDN but in subsequent calls to the CDN with the query string ?https added to the count.js call, the redirect just reverts back to mediacdn.disqus.com. I've tried this numerous times.
The annoying thing about this issue is that the SSL page in question on my site creating the mixed content notification does not even have a comment section. So Disqus is loading its javascript needlessly on the page.
I like Disqus but it's unbelievable to me they wouldn't fix this issue by either allowing users to disable the javascript selectively or by implementing a secure cdn version that works in all cases. I am hoping they figure this out.
Also they told me that Disqus 2012 doesn't support HTTPS (although it will be in the future).
Apaprently Disqus launched a new service that does not support SSL. This is what's generating the extra scripts that get loaded insecurely, thus triggering the security warning.
I have a Rails 3 app running on Heroku. For authentication I use devise. The session data are stored in a cookie.
Now when I use Firefox I can see the cookie - I use a Firefox plugin to see it; when I use IE I cannot see it: there is not cookie file getting set and when I use the developer console to view the cookies I get nothing. The web app is working fine in IE so somehow the cookie gets sent to the server.
What is going on? How can I see the session cookie in IE?
Thanks for any help.
-Matteo
Does your URL contain an underscore? Internet Explorer does not like underscores in the URL when handling cookies.