Firefox was working perfectly before we've updated it to version 30.0. It seems that the new version does not like our Proxy setting which needs users to auth with their AD accounts.
In the past version, Firefox will pop-up a box that allow you to type in the username and password, which works perfect. However, it does not pop-up anymore and gives me this error message.
The following error was encountered:
Cache Access Denied.
Sorry, you are not currently allowed to request:
http://www.google.com.au/url?
from this cache until you have authenticated yourself.
I try to manually set up the username in key chain and allow firefox to access it but Firefox seems do not access that key chain at all.
Is anyone have the issue with the proxy which needs authenticate in Firefox30.0? Does anyone know the possible solutions?
Many thanks!
Shuopan
trouble shoot update-----------------------------------------
Quite interestingly, Firefox will work for 1 minute after I am using Safari with that Auth proxy. However, if I am not touching Safari for 1 or 2 minutes, Firefox will stop working and pop up the similar error message.
tried network.http.use-cache = false but not work
Thanks
We find Philipp's solution is helpful.
This might be due to the disabling of certain insecure authentication protocols in firefox 30: https://www.mozilla.org/en-US/firefox/30.0/releasenotes/#whatsnew
You can do the following:
Enter about:config into the Firefox address bar (confirm the info message in case it shows up)
Search for the preference named network.negotiate-auth.allow-insecure-ntlm-v1. Double-click it and change its value to true.
https://www.mozilla.org/en-US/firefox/30.0/releasenotes/#whatsnew
Related
The browser reports that the connection is insecure, so the certificate hasn't loaded correctly. However, then manually opening the website it loads correctly.
Can anyone tell me how to fix Invalid certificate issue, It's result in to launching the wrong URL.
I tried with "chromeWebSecurity": false in my cypree.json, but no luck.
Please help me to solve this issue.
I haven't done this myself, but Cypress docs say that it's expected: You'll notice Chrome display a warning that the 'SSL certificate does not match'. This is normal and correct.
Note, that Cypress allows you to optionally specify CA / client certificate
https://docs.cypress.io/guides/guides/web-security#Examples-of-what-Cypress-does-under-the-hood.
So if the fake Cypress certificates are causing issues for you, you can try supplying your own certificates.
if it is not your website, you cannot fix it.
what you can do is verify why it is invalid, and decide to accept it and still open an https connection with the server although the certificate isn't valid.
usually the steps are:
click Advanced button
read and understand
click Accept or close the tab
the common reasons for a certificate to be invalid are:
domain name invalid, the certificate is installed for multiple vhost, and you have accessed the service for a domain name not defined in the certificate. www. is required, only * is specified without empty domain. totally wrong domain name. etc.
certificate is expired. check the date, it might be expired and decided if that makes sense to you
certificate isn't trusted, self-signed or using an authority not trusted by your browser.
if it is your website, these are the same reason, so you should be able to replace the certificate with an appropriate one.
by the way, this might not be a question for stackoverflow, maybe more for superuser, but I am happy to answer it anyway.
hope this helps you and others
cheers,
I am trying to perform HTTP get & put operations on a intranet URL which is authenticated using Microsoft active directory domain accounts. This is working fine with IE but not using chrome. My chrome version is 49.0.2623.108.
Accessing the URL throws up a dialog for username and password and upon filling details, it fails with ERR_INVALID_HANDLE. Following are the things that I tried and failed(Please excuse for the lack of brevity):
I tried adding the URL and the Active directory server to Local intranet zones but still chrome returns the same error.
This link https://serverfault.com/questions/19914/google-chrome-passthrough-windows-authentication says we need to use authserverwhitelist for chrome. It is not working. Apparently, this feature of setting parameters has been moved from commandline to policy settings as per https://bugs.chromium.org/p/chromium/issues/detail?id=472145
I tried using policy settings like using chrome policy template. I imported the policy template on local computer policies\Administrative templates in gpedit.msc and set the parameters AuthServerWhitelist and AuthNegotiateDelegateWhitelist. I restarted the machine as well. It didnt help. Chrome still throws the same error.
I tried setting AuthserverWhitelist and AuthNegotiateDelegateWhitelist parameters on registry as well under path: HKLM\Software\Policies\Google\Chrome.
Is there a way to get this working on google chrome(version 49.0.2623.108)?
PS: Also after development, I am looking to package these web pages into a chrome app. Would chrome allow usage of windows active directory authentication in its app environment? Is there any way to fix it?
Our Heroku application seems to be having a weird issue. The application works fine from Chrome or Firefox however when loaded in Safari I am getting the Heroku Application Error Page. We have a test instance running the same application with a custom domain and SSL endpoint but it doesn't have this issue. Also connecting directly to the Heroku url app-name.herokuapp.com works fine in Safari. It is only when using Safari and connecting to our custom domain does it give the application error.
The only thing I can think of is an error in the Heroku router, or the SSL endpoint.
I've tried clearing my cache, and changing the DNS for the Safari browser, and asked multiple other people to test and they are experiencing the same issue with Safari.
Has anyone else experienced this issue?
I found that if you forward your domain to Heroku with a "masked" domain while using Safari or iOS there are weird results.
In my case the server side session cookies will not be accessible.
It works perfectly on Chrome and Firefox.
I use Godaddy to manage the domain name but I do not think they are the caused.
When I remove the "masked" and strictly forward the domain to Heroku all platforms work.
I have an application that requires Windows authentication with fallback to Forms authentication. I built it in this way: http://msdn.microsoft.com/en-us/library/ms972958.aspx and everything works fine.
So basically I create forms authentication cookie for a domain based on the outcome of Windows authentication. The cookie is valid as long as the browser stays open. I do not have problems with that in Firefox or Chrome, not even IE8 on Windows XP machines. Unfortunately all Windows7 machines with IE8 experience the same problem: a login prompt shows up when you try to refresh the page after around 30minutes of inactivity. Even if I provide valid Windows credentials I still cannot log in to the application. Nothing helps, but closing the browser and starting it again. Then I am again logged in automatically and it will be fine as long as I stay active. After 30 minutes of inactivity - again log in prompt. After some research I found out that if I delete the auth cookie using developer tools (F12) and then refresh, I get automatically logged in without the prompt (just what you would expect from Windows authentication).
Does anyone of you have an idea what can go wrong and how can I get it to work correctly on Windows7 machines? Or maybe ideas on where to look? Is it IIS problem (I use IIS6 on Windows 2003 Server), client problem? What makes Win7 IE8 so special that it fails?
I don't know why it expires, but I managed to get rid of the problem. Somehow on IE8 on Win7 it cannot continue, because it tries to auth, but the old auth cookie is supplied. If I clean the cookies on the request and then forward to the login page, it works. It's not a solution to the problem, but at least the user gets re-authenticated...
We are getting security message like this while executing url:
There is a problem with this website's security certificate. The security certificate presented by this website was not issued by a trusted certificate authority.
Security certificate problems may indicate an attempt to fool you or intercept any data you send to the server. We recommend that you close this webpage and do not continue to this website. Click here to close this webpage. Continue to this website (not recommended).
More information
Same type of security alerts with message like this
This page is accessing information that is not under its control. This poses security rish, DO you want to continue?
How to avoid them through code either javascript, jsp or any way. We can not ask each user to modify their internet options. Please let me know if there is any solutions for this
That's browser behavior that you can't and shouldn't be allowed to modify using JavaScript, or anything else for that matter. In fact, these security alerts are there to warn the user that something is (potentially) wrong. If you could disable them, there would be no point in having them, right?
Fix whatever problems you have with the security certificate and you'll be fine. I'll guess here that your certificates are self-signed - buy one. They are not that expensive.
You need to install a current, valid certificate on your web server.
There is a problem with this website's security certificate could mean you need to check that the clock is set correctly.
Host all content on an https website. not an http one. You do not need a certificate then.
1> The security certificate presented by this website was not issued by a trusted certificate authority.
This message indicates that the page is using a HTTPS-based resource which has a certificate which does not chain to a globally trusted root certificate. If you don't know what resources/URLS are causing this, open the F12 Developer Tools and look at the Console tab, or run Fiddler and watch for the warning popup.
2> This page is accessing information that is not under its control. This poses security risk, DO you want to continue?
This message is shown when you attempt to use an XMLHTTPRequest object to request data from a cross-domain location (e.g. www.domain.com tries to grab data from domain.com). That operation is a violation of Same-Origin-Policy.
By default in IE, this is blocked, but inside the Intranet Zone, this feature is set to Prompt and thus you see this message instead.
To fix this, either change the request URL so that it does not go to a different domain, or use XDomainRequest, or use a serverside proxy page to make the cross-origin data request from the server rather than the client.