I am using nginx proxy to server my web-page. For login user need to provide his 2 factor authentication code and his password, to let users know that they need to enter their password+2 factor code to login, I send them a message "Login required, username, password+VIP token"'
And this what I get now
This has stopped working from Chrome version 49. I am on 49.0.2623.110.
Any work around to fix this? It works perfectly on firefox.
This was indeed answered in Change Basic HTTP Authentication realm and login dialog message.
Short explanation: You were actually defining realms with auth_basic directives of Nginx on the server side. But "whether to prompt this message or not" is basically a design choice made by specific client programs. And Chrome just chose to hide it, for reasons you may find in the first link.
In fact, as of my decade (2022), Firefox seems to hide the message too.
Why I necromance this very old post: I was reading this documentation of Nginx. At the end of the article, there is a screenshot similar to the Firefox one in the OP. Unsurprisingly, my browser didn't behave like that even I followed all the instructions therein. Then I started Googling and this is the first hit relevant to my question. After I learned something about HTTP basic authentication, realm etc and finally came across the first link, I think I should post something here.
Apparently, Nginx documentation is using kinda modern UI to host kinda outdated contents. Hope this answer will help anyone who is confused by that screenshot too ;)
Related
I've been trying to create a new collection at https://console.cloud.google.com/firestore/data?project={PROJECT} however when I do, nothing happens. Opening the dev tools and looking at the Networking tab shows the requests are not going through (see screenshot). I'm using Chrome 83.0.4103.97 on OSX 10.15.4 (19E287). I have tried to go to Site Settings and change unsafe content to Allow, however that did not make a difference.
Anybody got any idea how I could make it work?
#Alice and #Frank resolved it however I think this is worth creating an answer.
In such situation first thing to check if incognito window is behaving the same way. There might be some extension that are blocking request.
In this situation there was "Disconnect" extension which was blocking.
I hope it will help someone in future!
I'm getting this chrome flag when trying to post and then get a simple form.
The problem is that the Developer Console shows nothing about this and I cannot find the source of the problem by myself.
Is there any option for looking this at more detail?
View the piece of code triggering the error for fixing it...
The simple way for bypass this error in developing is send header to browser
Put the header before send data to browser.
In php you can send this header for bypass this error ,send header reference:
header('X-XSS-Protection:0');
In the ASP.net you can send this header and send header reference:
HttpContext.Response.AddHeader("X-XSS-Protection","0");
or
HttpContext.Current.Response.AddHeader("X-XSS-Protection","0");
In the nodejs send header, send header reference :
res.writeHead(200, {'X-XSS-Protection':0 });
// or express js
res.set('X-XSS-Protection', 0);
Chrome v58 might or might not fix your issue... It really depends to what you're actually POSTing. For example, if you're trying to POST some raw HTML/XML data whithin an input/select/textarea element, your request might still be blocked from the auditor.
In the past few days I hit this issue in two different scenarios: a WYSIWYG client-side editor and an interactive upload form featuring some kind of content preview. I managed to fix them both by base64-encoding the raw HTML before POSTing it, then decoding it on the receiving PHP page. This will most likely fix the issue and, most importantly, increase the developer's awareness level regarding the data coming from POST requests, hopefully pushing him into adopting effective data encoding/decoding strategies and strengthen their web application from XSS-type attacks.
To base64-encode your content on the client side you can either use the native btoa() function, which is supported by most browsers nowadays, or a third-party alternative such as a jQuery plugin (I ended up using this, which worked ok).
To base64-decode the POST data you can then use PHP's base64_decode(str) function, ASP.NET's Convert.FromBase64String(str) or anything else (depending on your server-side scenario).
For further info, check out this blog post that I wrote on the topic.
In this case, being a first-time contributor at the Creative forums, (some kind of vBulletin construct) and reduced to posting a PM to the moderators before forum access it is easy for one to encapsulate the nature of the issue from the more popular answers above.
The command was
http://forums.creative.com/private.php?do=insertpm&pmid=
And as described above the actual data was "raw HTML/XML data within an input/select/textarea element".
The general requirement for handling such a bug (or feature) at the user end is some kind of quick fixit tweak or twiddle. This post discusses the option of clearing cache, resetting Chrome settings, creating a new_user or retrying the operation with a new beta release.
It was also suggested that one launches a new instance with the following:
google-chrome-stable --disable-xss-auditor
The launch actually worked in this W10 1703 Chrome 061 edition after this modified version:
chrome --disable-xss-auditor
However, on logging back in to the site and attempting the post again, the same error was generated. Perhaps the syntax wants refining or something else is awry.
It then seemed reasonable to launched Edge and repost from there, which turned out to be no problem at all.
This may help in some circumstances. Modify Apache httpd.conf file and add
ResponseHeader set X-XSS-Protection 0
It may have been fixed in Version 58.0.3029.110 (64-bit).
I've noticed that if there is an apostrophe ' in the text Chrome will block it.
When I update href from javascript:void(0) to # in the page of POST request, it works.
For example:
login
Change to:
login
I solved the problem!
In my case when I make the submmit, I send the HTML to the action and in the model I had a property that accept the HTML with "AllowHTML".
The solution consist in remove this "AllowHTML" property and everything go OK!
Obviously I no longer send the HTML to the action because in my case I do not need it
It is a Chrome bug. The only remedy is to use FireFox until they fix this Chrome bug. XSS auditor trashing a page, that has worked fine for 20 years, seems to be a symptom, not a cause.
We have a site that is not working in Google Chrome V44. It works well in IE and Firefox. All of sudden after updating chrome browser to V44, we unable to login to the system and just receiving this problem.
We're trying to figure out as why this is happening. We have 2 instances of our system in our server. Our live site is the one that is not working in Chrome V44 while the other - our demo site is fine. The only difference of the these sites is that our live has SSL. So our first impression is that there's a problem with Chrome V44 with our site with certificate.
I think Chrome can't establish secure connection with the site.
Has anyone experienced this issue?
Please help. Thanks.
This is due to a SSL in Chrome V44 where it incorrectly sends a HTTP_HTTPS header to be set, however the HTTPS header is still set correctly. It has been quite widely reported: http://www.zdnet.com/article/brand-new-chrome-44-release-added-a-bug/
https://ma.ttias.be/chrome-44-sending-https-header-by-mistake-breaking-web-applications-everywhere/
In order to stop this, in PHP, I added the following to the very top of my index.php file:
<?php
if (!isset($_SERVER['HTTPS'])) {
$_SERVER['HTTP_HTTPS'] = 0;
}
?>
Ensuring there is no space between the ?> and the next
I've recently had the chrome redirect loop on gmail.
Possibly significantly, I was doing some work involving changing my system time and it hasn't worked since. This guide helped to do that.
There is an available work-around, which is to use gmail in incognito mode, which does still work, although requires you to log in each time
In that case I would say this is an internal problem with you organization's setup. I would speak with your SysAdmin or IT staff. But just to be sure, use your phone carrier's internet, or a cafe nearby, basically something off your network to check if you can reproduce the error.
The issue with my MVC solution was, i had recently updated complete Nuget packages in my solution. After the update i forgot to update
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
section with new dll bindings which installed while update. So in my hosting server due to connectionstring issue, i was not overwriting the current .config file. So once i did the update in assemblyBinding section in .config file the issue gone.
There might be many reasons for the redirect loop. If you are confident your setup is done properly without any errors, then it might be the issue with your browser. You can try the following
Deleting cache and cookies
Correcting your system time (if it is not set to automatic)
Resetting the browser
Source
You should be able to fix this problem, you can try to clear your cookies in your browser
Open your Chrome browser.
Type "chrome://settings/clearBrowserData" in the address bar and press Enter.
Make sure you are clearing items from the Beginning of time. Then select Cookies and other site data. Click the Clear browsing data button.
If find from google search, this tutorial could helps you https://windows10freeapps.com/fix-err_too_many_redirects-error-google-chrome-browser
I'm attempting to load a page that does a call to ADFS for authentication purposes. On the page load, there is a redirect and then popup to enter credentials.
HTTPS must be used.
Chrome must be used as the testing browser.
So, when loading the page everything is working fine, but I'm forced to manually enter credentials when running the test. After inputting the credentials everything is fine, but is there a way to leverage Watir to input this for me? I've tried popping the username:password into the link already with no success, and since I really need to use Chrome the Firefox plugins are moot.
require 'watir-webdriver'
b = Watir::Browser.new :chrome
b.goto 'https://internalUAT.clientwebsite.com/'
b.link(:text => 'HR Dashboard').click
I'm not allowed to post images due to reputation constraints, but please visit
https://i.imgur.com/ExVt8fp.png
for a screenshot.
When you try passing credentials with the https://user:pass#foo.com technique, do you have any unusual characters in the username or password? (Maybe you have a DOMAIN\username domain prefix?)
If so you might want to make sure any such characters in the credential string are properly escaped.
If that's not the problem, and there's no other way to disable the auth prompt for your tests, then your best bet (IMO) is to write a separate script (or thread) that uses RAutomation (or some other UI automation library of your choosing) to enter your credentials and click the Log In button.
See https://github.com/jarmo/RAutomation
The test cases in the following file contain examples of using RAutomation's send_keys method, which could prove useful:
https://github.com/jarmo/RAutomation/blob/master/spec/window_spec.rb
For the record, it looks like RAutomation may have been used by watir-classic for dialog handling:
https://github.com/watir/watir-classic/blob/master/lib/watir-classic/modal_dialog.rb
http://www.rubydoc.info/github/watir/watir-classic/Watir/ModalDialog
I've got a client that sees the "Page can not be displayed" (nothing else) whenever they perform a certain action in their website. I don't get the error, ever. I've tried IE, FF, Chrome, and I do not see the error. The client sees the error on IE.
The error occurs when they press a form submit button that has only hidden fields.
I'm thinking this could be some kind of anti-malware / virus issue. has anyone ever dealt with this issue?
In IE, go to the "Anvanced" section of "Internet Options" and uncheck "Show friendly HTTP errors". This should give you the real error.
Is this an IE message? Ask them to switch off "short error messages" (or whatever they are called in the english version) somewhere deep in IEs options - This will make IE display the error message your server is sending instead of its own unhelpful message.
Also I've heard that IE might be forced to show server provided error messages if only the page is long/large enough, so you might want to add a longer " " section to error messages. This information is old enough that it might have effected older versions of IE - I usually get to the root of problems with eliminating the "short error messages"
Note: I'm neither running IE nor Windows, therefor can only operate on memory regarding the name of the config options of IE6...
Update: corrected usage in the suggestion to provide longer error messages... Perhaps somebody with access to IE can approve if longer error pages still force IE to display the original error page instead of the user friendly (sic) one.
It would be useful to you to figure out which error code is returned. Is it 404 - Resource not found or 503 - Forbidden Access? There are a few more, but in any case, it would help you figure out the cause of the problem.
If your client is running IE, ask him to disable friendly error messages in the advanced options.
Check their "hosts file". The location of this file is different for XP and vista
in XP I believe it's C:\windows\hosts or C:\windows\system32\hosts
Look for any suspicious domains.. Generally speaking, there should only be ~2 definitions (besides comments) in the files defining localhost and other local ip definitions. If there's anything else, make sure it's supposed to be there.
Otherwise, maybe the site's just having issues? Also, AFAIK, FF never displays "Page cannot be displayed", so are you sure this is the case in all browsers?
You can try using ieHTTPHeaders to see what is going on behind the scenes.
Do you have any events applied to your submit button? Are you doing a custom submit button that is a hyperlink with an href like "javascript:void(0)" and an event attached that submits the form?
Alought this is a 2008 thread,
but I think maybe someone still use windows xp in the virtualbox in 2018 like me.
The issue I met in 2018 is:
1. Ping to 8.8.8.8 can get correct responses.
2. HTTP sites is working fine, but HTTPS is not.
3. I cannot connect to any site with HTTPS so I cannot download Chrome or Firefox.
And my solution is to enable the TLS 1.0 for secure connections
Everything is fine.