We have a secure website (SSL) in which we want to make calls to google's map server. The map server is http not https and every time there is a refresh of this screen (every minute for us) IE pops up its annoying mixed content message (trying to view a site with secure and non-secure info).
What I am looking for is a way around this. For example, is there a way to proxy the request so that our internal request is https but the other side of the proxy is not secure? I'm trying essentially to spoof the data to trick the browser.
Any ideas here? The actual security of the end point is less important than avoiding the error message itself.
Thanks!
Don
There is a way to suppress this at browser level, which might not be desirable for you, but I thought I'd throw it out there. In IE, Tools | Internet Options | Security | Internet Zone | Custom dialog box, you can set the "Display mixed content" to Enable. It's probably on prompt right now. Again, this is a single user browser level setting, so probably will not work for you. This does open up a lot of problems security wise though, and most admins will not do this (DNS poisoning, m-i-m etc).
Your second option is to become a premier customer: http://code.google.com/apis/maps/faq.html#ssl
Your third option is to use Virtual Earth - which supports native SSL w/o any strings
EDIT see similar question: here
As of March 2011, the Google Maps API is available to everyone over SSL:
http://googlegeodevelopers.blogspot.com/2011/03/maps-apis-over-ssl-now-available-to-all.html
Here's the problem with that. Even though the API is SSL the thumbnail images the map has for locations are NOT ssl. So you can still get a message.
remove runat="server" from head, where you are using code to link API to your page
Related
I have been developing a system in .NET MVC and have up until had no problems logging in; however today I tried to log in on Chrome and the form is not being submitted instead I get the following error in the console:
This page includes a password or credit card input in a non-secure context.
A warning has been added to the URL bar.
For more information, see [Link Here]
I have verified that the log in page works in another browser (Firefox) and can confirm there is no issue in that browser. Is there something I can do short of converting to a HTTPS site, this is a test server for the company I work at and so they don't use HTTPS on in development websites.
I would expect (as Uwe Keim mentions) that you'd want to heed the warning and maybe discuss with your colleagues WHY they aren't testing with HTTPS if they use (or will use) it in Live? Self signed certificates can be used for these things so it doesn't involve a cost for internal-only development kit.
If that is a no-win situation, perhaps you may gain some benefit by adding it to your trusted sites list?
Whenever I try to visit log in to PayPal on Google Chrome (my current version is 35.0.1916.114 which is the most up to date at the time of writing this), I get a 500 Internal Server Error. Here's the exact one:
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator, webmaster#paypal.com and inform them of the time the error occurred, and anything you might have done that may have caused the error.
More information about this error may be available in the server error log.
I'm able to visit the homepage fine and I can log in on all other browsers but this has been an issue for some time now (I just haven't gotten around to looking into it). At the moment, I open Firefox just to use PayPal but I used Chrome for everything else so I'm trying to solve it.
Any ideas on why this would be happening? I've seen other questions on the web similar but they are mainly due to people 'buying' through PayPal which isn't a problem for me. I can purchase items on the 'purchase' screens that you get redirected to from a site.
Thanks for your help!
I see this from time to time on a couple of very specific web sites (e.g., Slashdot). All other sites works fine when this happens (and the site works fine in other browsers, including Web Kit based ones). The embarrassingly simple solution is to restart the browser (I try to avoid it since I often have 50+ tabs open). If guess the problem might be session cookies (that would explain why a restart works). As a consequence of this guess, clearing all permanent cookies for PayPal and related sites might be worth considering.
For me, I do like this at the 500 error page
Click on the Secure to the left side of the address bar
Select Site settings
Select Reset site settings at the bottom of the page
Reload the page
in some cases but not all. There appears to be a corrupt session via the cookie or data stored for a specific browser in the java files. Try the following;
1. Download CCleaner (close chrome)
Remove and clean registry files
Remove tmp and cached for CHROME as well as cookies
Clear index.dat file
4. Control Panel / Java-open / clear internet java cached files
5. Make sure you're not using a proxy IP for the web
6. Restart computer
7. Try again
Now that Google separated cookies from permissions I had to delete my cookies separately to get it to work.
Click on the Secure to the left side of the address bar
Select Cookies
Select the wordpress cookies and Remove each one
Reload page
I'm implementing a mutual authentication for my client in order to solve not having to continually whitelist some of the agencies with a dynamic ip. The process works fine in all browsers that I've tried in the Windows environment (Windows 7).
The problem is that there is a popup for every time that the user goes to the site. On most browsers, this is a one time occurrence, when you first go to the site for the day. On Google Chrome, however, the popup occurs on what appears to be every POST/GET request. I found how to disable the popup for IE and FF with this link: http://docs.threerings.org.uk/wiki/Certificates_without_prompting, but there is still the problem with Chrome.
I've tried to install the certificate into the Trusted Root Certification Authorities, but I get an error message, "The import failed because the store was read-only, the store was full, or the store did not open correctly.".
If anyone has an idea on what I can do to get around the pop-up for Chrome, it would be greatly appreciated.
This is what you're looking for:
http://www.chromium.org/administrators/policy-list-3#AutoSelectCertificateForUrls
I could tell you how to do it exactly, but my honest opinion is that this is something you have to work out yourself. You need to know what is going on because you are more than likely to run into bugs (not bugs per-se but some undesired or unwanted results).
I have to admit that Google Chrome and Chromium are great browsers, but when it comes to client certificates, they have a lot of improvements to be made.
Just some extra info on this that may help people.
The first part references the CFBundleIdentifier which you can find in the Contents folder then info.plist. Click you Application and then show package contents then you should see it.
So I had to do this for Chromium for Tizen debugging below worked obviously use your CN name.
defaults write org.chromium.Chromium AutoSelectCertificateForUrls -array-add -string '{"pattern":"*","filter":{"ISSUER":{"CN":"Entrust Certification Authority"}}}'
I have a website with an authentication form that users must use to access the site.
When Google Chrome is used to access the site, there is no offer to save the user's credentials, despite browser settings being set to allow. The FORM tag is not using autocomplete="off", but it is running over HTTPS if that makes any difference.
What do I need to do (or not do) for Chrome to offer to save passwords?
FYI - the site in question can be seen here.
It turns out that the issue was caused by the tag missing the action attribute.
Added action="" and all is good, even with AJAX and GET.
I don't think chrome remembers usernames and passwords sent via AJAX. The only thing you can do is make it submit the form normally.
Apart from Nathan's observation on the use of XHR to post the credentials, it is quite possible that the use of the HTTP GET instead of the HTTP POST request is responsible for Chrome's behavior in not offering to save the credentials.
It should be noted, that using HTTP GET instead of POST to submit credentials is often considered a bad practice in itself, notwithstanding the annoyance encountered in Chrome. Although I cannot pinpoint any specific problems in this case (as I haven't seen the post-login page, and other related traffic), using GET to transmit credentials is something you would want to avoid (to prevent any potential leaking of credentials, despite the use of HTTPS).
I want our app to show the online help page (so it's always up to date) or even a local page. However, it's likely to be blocked by the Firewall (Zone Alarm).
BTW, I tested this with Zone Alarm. It blocked access to a local .html file as well as to an .asp file on the internet. (I.e., tried to display a page in Internet Explorer and got the Zone Alarm dialog asking if I wanted to give permission to display
Is there a way around this?
Perhaps displaying the web page in the Web Browser Control?
It's actually very unlikely that web traffic is blocked at the firewall (unless you mean the file type is blocked?). What you may need to do in such a setting, however, is use the same proxy that IE uses, because direct traffic may be blocked.
The simplest way to do that is to use a high level windows API or IE itself, and HTTP download the latest helpfile if there is a new one - these mechanisms should know about any proxy.
Of course, your users may not be using IE, even if most are. So you might need to allow the user to specify the proxy, or be able to auto configure the proxy in the same way that the browser does it.
edit: I see you mean zonealarm is part of the problem. yes, that is tricky as you will have to either get your application 'blessed' centrally by whoever manages zonealarm in the customer organisation, or (if there is no central management) then the user will have to allow the app to communicate. Perhaps you should bite the bullet and have the online help simply be a website, and spawn the preferred browser via 'executing' the URL as suggested in another answer.
If the web browser isn't blocked the firewall then they probably open port 8080 for any app and thus your app shouldn't be blocked.
If the firewall only allowed port 8080 to IE; you would have to punch a hole in the firewall to use a new browser like firefox or chrome.
To open a web page using the user's preferred browser (with appropriate proxy and authentication settings), use something like ShellExecute with the URL of the document to load. Something like this would do it (where page is the URL to load):
HINSTANCE r = ShellExecute(NULL, "open", page, NULL, NULL, SW_SHOWNORMAL);