Migrating my website to a secure server, a frame is being blocked by browsers because of a security issue which doesn't happen on my existing website, which is hosted on an http server. [Google Chrome Developer Console screen shot][1] [1]: https://i.stack.imgur.com/wQkpr.jpg
The page should load a calendar, but it does not do so.
I'm not a coding expert, and don't know how to resolve this. The issue happens when loading this page:
Page which generates DOMException
However, the site under development is hosted on a non-public server. In order to access it, the hosts file on a Windows platform would need to have this code added: 199.168.187.45 mauitradewinds.com www.mauitradewinds.com secure.mauitradewinds.com m.mauitradewinds.com
Without adding that code to the hosts file, a browser would be redirected to my existing http site, which is not where the issue is happening.
I'd be grateful for guidance on how to eliminate this frame blocking.
My guess is you have a protocol conflict between your iframe and your main page.
Your main page is accessing through http and the iframe through https.
Your existing website most probably has a redirect from http to https which is why the issue is not happening on the existing site.
A web developer solved this by observing that adding www to the URL would prevent the DOMException, and allow page frame content to load.
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?
My site is in Rails 4.1.7 and is hosted in Ninefold.
I want to verify and add Google Analytics to it.
I tried uploading html file in public folder, no go.
I tried creating controller and route, didn't work.
I tried a couple of solutions that were supposed to do a workaround in turbolinks and added the analytics script to the footer. Didn't work
Any ideas?
I must add that in the first two solutions, the html / action were accessible through the browser call but not through external links (when you try to verify, it gives you a link in webmasters tools), which has led me to believe it's a csrf situation, where rails blocks incoming connections from other websites.
UPDATE: I have this solution live, analytics shows me some data but site verification still does not work.
UPDATE 2: Ok, i solved it. The problem was that i had stated the domain as domain.com in Ninefold and forgot about it, and then i was trying to verify www.domain.com in Google. Solved by adding the extra domain and verifying both of them.
The method for including scripts in my wordpress plugin is in another post: how to load jquery dialog in wordpress using wp_enqueue_script?
I think this works fine for me, but I'm getting a weird error in the Firefox development tools console when I load my page, after enqueueing the jquery-ui stuff (js and css). Here is my code:
wp_register_script( 'myplugin-jquery-ui', plugins_url("myplugin/js/jquery-ui.min.js" ) );
wp_enqueue_script( 'myplugin-jquery-ui');
But when I load the page in Firefox, the console says:
Cross-Origin Request Blocked: The Same Origin Policy disallows reading
the remote resource at
http://fonts.gstatic.com/s/opensans/v10/u-WUoqrET9fUeobQW7jkRT8E0i7KZn-EPnyo3HZu7kw.woff.
This can be fixed by moving the resource to the same domain or
enabling CORS.
I can't find "fonts.gstatic.com" referenced ANYWHERE in ANY of my files, least of all the jquery-ui.min.js file. Can you please help me understand a) why/how I'm getting this error, and b) if it's something I should just ignore?
And if I only need it for the dialog plugin, should I do be doing this differently?
This is a bug by Google. It's not serving the header correctly sometimes for reasons only they know. A bullet-proof way to prevent this shame is get the font files and serve them yourself.
You can verify the received headers when the woff is served and you will se how they are not sending the header when the browser fails to load the font. If you can't believe your browser, check with a network sniffer tool like Wireshark.
I have successfully implemented MVC bundling for my MVC application. There is one problem with the run time which runs under HTTPS.
I am sure there is a problem because when I switch the debug field to false the user gets the warning message "This page contains secure and nonsecure items. Do you wish to proceed?
I know that I can turn this prompt off using the security setting in IE. I would like to know if there is something I can do to the application so that bundled scripts and styles come through the secure pipe.
If you use the Scripts.Render helper to include the bundle it will use the same HTTP scheme as the one used to request the main page. So if the main request was done over HTTPS then this helper will generate a <script> element using HTTPS. You could use the Net tab of FireBug to see which resources are served through HTTP and HTTPS and be able to isolate the problem.
Thank you for this suggestion. I figured out that the problem was coming from modernizr-1.7.js
The strange thing was that this problem only occurs when modernizr is bundled. I removed modernizr because we don't really need it.
Since moving my JQM site to my live server I'm getting a few problems!
I have a dialog that appears using the slidedown transition on my test site.
When I move to my live site, it is loaded like an external page with no transition.
The reason for this is the URL for the dialog.
If I have the url as http://mysite.com/dialog.php it works perfectly with the slidedown transition.
If I have the url as https://mysite.com/dialog.php it loads with no transition.
It looks like using https rather than http is causing the issue.
Does anybody know a way to fix this?
Verify if your assets (js/css/images etc) are all served from secure url. There are browser policies that may restrict a secure url from loading non-secure assets.