I previously set a directory on my web server to require a username/password during development phase. I have since removed the .htaccess file to remove the password, I have also checked the cPanel to make sure there are no settings for a user/password.
Despite this, Chrome keeps asking for a username/password. If I click Cancel, the page continues to load anyway.
This only happens on Chrome Windows and Mac. I have cleared the entire cache for Chrome but to no avail. I am not able to replicate the problem on Firefox 4 or Internet Explorer 9.
I figured it out. I was silly enough to have left the URL pointing to a domain which does ask for a username/password but the domain it was pointing to was for the development site. Not sure why the other browsers didn't do the same thing but updating the base href has solved the problem.
Related
I've been playing around with GitHub pages for a while, and have been doing most of my development in Firefox. Everything was working amazingly, until I attempted to test my project page in Google Chrome. To my surprise, when visiting the same GitHub project page in Firefox and Chrome, Firefox was served the correct index.html page while Chrome was served a completely different (and incorrect) one.
I've poked around for a few hours now and honestly have no idea what's going on. Both Firefox and Chrome are requesting the exact same URL with an HTTP GET request and receive different responses from the server. I've tried changed the user agent and messing with the request header in both browsers, and it didn't seem to affect anything.
Does anybody have a clue what's going on? If it helps, the project page in question is "https://wgxli.github.io/complex-function-plotter/". Any help is much appreciated.
Edit: It appears to be related to a browser cache issue. The behavior disappears if I clear all data from the browser and visit the above page. However, if I clear the browsing data, visit the root directory of the above page, and then request the above page, the problem reproduces itself. At this point, I think I've reduced it to a question of why the browser (or CDN) is returning a cache hit when it shouldn't.
I ended up fixing the issue. I was using create-react-app, which automatically registers a service worker for local caching. I just disabled this service, which resolved the problem.
Our website has been recently hacked (Joomla 1.5, hosted on VPS). Attacker added few php scripts that were redirecting to some ad sites. We have cleaned everything (or at least we think we did), and now everything works as it should.
However, links on Google (or Yahoo) that are pointing to our web site are still trying to include these php scripts (and returns 404 as these are deleted now). Direct links from browser works as they should.
We have cleaned site 10 days ago, so I do not think that something is cached at Google servers. Re-indexing should be done by now.
To reproduce this behavior:
Go to www.google.com
type in "anitex socks"
click any php link that starts with "anitexsocks.com"
You will get "The requested URL /wp-includes/client.php was not found on this server" + 404 error
Refresh page and everything works without issues
Why are only Google links making troubles?
Any help is welcome. Thanks!
As for the reason why this is happening, I installed a firefox add-on which blocks my browser's Referrer Header and then followed a Google link to your site and it worked fine. Then I disabled the add-on and the problem started occurring again.
This shows that there is still some malicious code running on your website which is checking all http requests to see if they come from Google (based on checking the HTTP Referrer header) and redirecting them to /wp-includes/client.php if they do,
To try to determine where this code may lie, try performing a recursive grep through all your www files on your server as well as your www configuration files,somewhere in there there must still be a reference to that client.php script, hopefully you can find and eliminate it.
That said, if it were my site and I knew a hacker had had free reign over my server to do whatever they wanted to it, I would not mess around with trying to undo the damage and would instead restore the most recent backup from before the site was hacked. You only have to miss one back door the hacker left in place and they can re-enter your site. After restoring backups, you should also upgrade/reconfigure the software they used to gain access in the first place so they can't simply rehack it in the same manner again.
I think this should be releated to IIS settings but don't know exactly what it is.
As you can see below, this login message pops up for each images, 8 images 8 times in Opera.
And the major browsers react to this page different.
IE9 works good(this is the reason why I found this problem now. It's internal site and almost every users use IE...)
Chrome(17.0.963.56 m) works good.
Safari(5.1.2) is also good.
Opera 11.61 has a problem like I said...
And FF SHOWS NO IMAGES and don't even ask for login. And Firebug says it's "NetworkError: 404 Not Found!".
I don't know what's going on.
This site requires to login and it's internal, so I can't give you the link. Sorry for the inconvenient.
And this site is running on Windows Server 2003. And the image containing folder is shared for web(I don't know why it's shared. But don't want to change the setting). I don't know this may cause this situation.
If Opera opens a user name/password dialog, the site is probably sending a WWW-Authenticate header in response to those image requests. You can open Opera's developer tools ("Tools > Advanced > Opera Dragonfly" or right-click in page and select "Inspect element") and use the network feature to inspect the full headers.
I don't know how you can disable this header if it is sent, it depends on the server settings and what type of server you're running, and I'm not at all familiar with Windows Server 2003.
I am developing a Drupal site, within which is a page with an iframe, displaying an external SQL Reporting server driven site.
This iframed site is protected on by HTTP authentication. In all browsers, apart from Chrome, when the page is viewed, the browser driven login box pops up.
In Chrome (Windows & OS X), no login box appears and I get an immediate 401 error from the SQL Reporting Server. I've cleared cache's and even tried on a fresh chrome installation on a VM.
The above method works fine on the clients existing live site, which is ASP driven. Other than CMS technology, the only other obvious difference is domains.
The working live site is referencing a sub domain of itself in the iframe. The development site is referencing a completely different domain.
I've tried /Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome -–allow-cross-origin-auth-prompt, which seems to make no difference.
Does Chrome have much tighter cross domain login rules? Or am I missing something else?
According to the devs at chromium, this was an intentional change to protect against phishing attacks. If you say the prod sites reference the same domain, you shouldn't have any issues.
http://code.google.com/p/chromium/issues/detail?id=91814
To switch the (in my mind stupid) security-feature off set Browser flag:
--allow-cross-origin-auth-prompt
In Linux close all Browser Instances and type in terminal:
chromium-browser --allow-cross-origin-auth-prompt
For Windows, Mac, Android... take a look here: http://www.chromium.org/developers/how-tos/run-chromium-with-flags
See http://www.chromium.org/administrators/policy-list-3#AllowCrossOriginAuthPrompt for the policy that can be set versus using flags.
On Windows this can be set via the registry at HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Google\Chrome. See http://www.chromium.org/administrators/policy-templates for more information.
A cheeseburger to the first person who can help me make sense of this. I have a page in a Sharepoint app that uses Telerik's RadUpload to upload files. This has worked for months; last week it stopped working (in Internet Explorer, this detail is important). After talking with a co-worker about the problem, I tried the upload with Firefox; it worked. Not only that, all subsequent uploads from Internet Explorer started working. Flash forward an hour, and the aforementioned coworker, on another Sharepoint site, running on different servers, was having problems downloading (using Internet Explorer). Being half serious, half smart-aleck, I said 'try it in Firefox'. Not only did that work, ALL SUBSEQUENT DOWNLOADS IN INTERNET EXPLORER WORKED! And he re-produced this behavior on another machine. My fear is that this a browser issue. All advice will be greatly appreciated.
a
IE will try and present credentials to a server it knows to be in its Local Intranet zone when it tries to connect (depending on the setting of "Automatic logon only in Intranet zone").
Firefox will only present credentials when prompted, and will generally ask you by popping up a box (unless you've configured a list of sites for it to always present NTLM credentials to).
I've seen a similar case with Sharepoint where you can cause IE to work by logging in with Firefox. I theorized it was due to a permission on a remote resource being for "Authenticated Users", and you're causing your user to authenticate by logging in forcefully. We eventually set the "Automatic logon only in Intranet zone" to "Prompt" and it worked. My theory there was that it wasn't detecting the site as being in the Local Intranet zone for some reason. If you're not accessing a domain with no .'s in it, try also setting your Local Intranet site policy to match the full domain of the Sharepoint server, not just *.example.com - I've read that that can help.
Was it as simple as IE not re-downloading miss-cached .js file, maybe, that firefox did download, making IE work after that?
Pretty gnarly to debug.