I recently renewed my domain name after it expired. However, when I try to view my website, a login box popups.
This is new. I tried putting in my wordpress admin username and password all to no avail. Infact I get a '401 Authorization Required' error.
I have been at this for some days now. I contacted my hosting provider. They said they could view my website and that everything is fine. They however instructed me to clear my browser cache and cookies, which I have done. Still, the problem persist.
I tried viewing the site with an IP proxy site and truly I could see my website without any errors or login pop up box.
How do I solve this problem?
A 401 request usually means that your client (e.g. your web browser) is not able to authenticate itself with the server therfore cannot view the resource.
You have cleared your cache and cookies and you're prompted by a login
box, following this a 401 error appears. The site is viewable from
proxy.
Things to check,
Flush your DNS
Are the login details correct? its possible to get this error from incorrect logins
Check the URL for errors, make sure you're using the intended url
Try deactivating your wordpress plugins if problems still persist
Any further information you can provide, including images would help a lot.
Related
I have a website in production server, asp.net webforms using Asp.Net Identity system.
Sometimes, when users tries to login, it redirects then back to login page after successful authentication thereby denying them access to user dashboard and other secured pages.
The temporary solution to this is for me to Recycle Application Pools in the hosting server (via plesk). But it appears again after some time. Sometimes before 24hrs or more.
The issue most often occurs when multiple users are getting logged in at a range of time... From my observation.
I don't know the main cause of the issue and I'm seeking a permanent fix to it. What could be the issue? How can I resolve this?
Useful hint:
After authentication at the login page, I usually create a response cookie which holds other value which I use to keep track of the user. If the cookie expires, I redirect the user back to login. I usually check for existence of this cookie on the master page for each page load. So I don't know if this could be a possible cause. If it is, whats the best practice to employ?
I've tried checking the cookies being set if it's the possible challenge, but no success.
I have logged into my Drupal 7 site as an admin and I was trying to put the site into maintenance mode but I get this response when ever I try:
"The requested URL was rejected. Please consult with your administrator. Your support ID is: 1272530.."
I have checked the permissions and it seems like my admin accounts has all the permissions granted. What could be the issue
Try this method. Hope you will get result or at least you get some idea.
Option 1: Clear your cache and browser then try to hit the url.
Option 2: Try from different network.
Option 3: Try cloning your site locally and check whether it's working in local system. I think firewall may be the issue in your web site server.
Our ASP.NET application is hosted in IIS 7.5 and has the following setup:
main site is hosted under root IIS folder accessible with http://siteurl (1)
we have a separate app in the same AppPool hosted under http://siteurl/Intranet (2)
Main app (1) has Anonymous Authentication enabled along side Forms Authentication (url: siteurl/loginform).
Second app (2) has Integrated Authentication (NTLM).
The login procedure works as following:
User goes to siteurl first
User gets redirected to /Intranet to check integrated auth
If integrated is accepted user gets redirected back with proper auth cookies to siteurl and gets access to the site
If integrated fails user gets redirected to siteurl/loginForm to manually fill in credentials
We have some issues with Internet Explorer (8, 9, 10) that refuses to submit the form data at step 4. It appears to be a known behavior that IE will not POST content to an unauthenticated site once the NTLM negotiation started for that session. I have considered some workarounds for this:
store credentials in a cookie (with JS) and on the server if the POST content has 0 length try to check the cookie values. delete the cookie afterwards
send credentials using GET instead of POST (ugly as we need to make sure the user does not see his just posted password in the browser address bar)
Provide a link to the user to open a new tab and continue the auth process in a separate browser session (this seems to work as IE will happily send POST data from a second tab)
Are there any other options we might have to get around this issue?
From the above 3 which one would be preferable and what unconsidered pitfalls we might encounter?
I wrote about this issue here: http://blogs.msdn.com/b/ieinternals/archive/2010/11/22/internet-explorer-post-bodies-are-zero-bytes-in-length-when-authentication-challenges-are-expected.aspx
Your question omits important information which makes it hard to troubleshoot. You should never see the problem described with the literal URLs you've used, because IE uses protection spaces to decide whether a site is going to demand credentials via a HTTP/401 and example.com/ and example.com/foo/ are different protection spaces.
It would be very helpful if you could share a Fiddler log of this scenario for better troubleshooting.
I'm using Drupal 7 with Varnish. Recently I noticed that the login and sign up blocks are not working for anonymous users. When a user tries to login or create an account via the blocks the user is just redirected to the same page however the new accounts are being created and the user session is also created. Is worth mentioning that if the users tries this via sign in/sign up page they don't have any issues. The problem happens only when using the blocks.
I'm thinking the issue could be related to Varnish. I tried disabling the Varnish module but the issue is still there. Also I tried using the ESI module so that blocks will not be cached but that didn't do anything.
Does anyone has an idea what may be causing this problem?
I guess there's a missing "Vary: Cookie" header in the original response, but it's hard to tell without the full headers and VCL.
ESI module won't affect login block AFAIK
I have a webapp which is a .NET 4, webforms app running on IIS 7.5 on Server 2008. Recently and apparently sporadically users trying to use the app on a mac are being presented with an error page stating:
401 Unauthorized - Access is denied due to invalid credentials.
You do not have the permission to view this directory using the credentials that you supplied.
The page doesn't provide any further information or substatus codes. I have checked the IIS error logs for more information and have found that this issue does seem to be unique to users on a mac most commonly Safari but it does also happen on other browsers such as Firefox. Again no substatus code is provided in these logs.
The error message provided seems to be consistent with a 401.1 however I am using forms authentication and not windows authentication. I have been unable to reproduce this myself and at the moment it apparently happens at random for users and not consistently after a set of specific steps.
This error occurs when users are in the app or trying to log in, I do not think it is related to them entering invalid credentials as I have validation to handle that and it can happen to users already logged into the app.
As I can't reproduce the error I am not sure how to approach solving this problem, I would like some guidance to this regard and any solutions or ideas that you guys can come up with. If more information is needed let me know and I can update the question.
EDIT:
I had an idea that maybe some configuration on a mac was causing a WWW-Authenticate header to be sent when it isn't required, but after using TamerData to add the header I found I still couldn't replicate the issue. All authentication in IIS is disabled with the exception of anonymous and forms.
EDIT 2:
I have now been able to successfully reproduce the issue, it occurs when an unauthenticated user attempts to access a protected page with a ?ReturnUrl=value parameter. This will cause IIS to display the error page described above. I can fix this behaviour by removing the ReturnUrl parameter on any unauthenticated attempts to access a protected page and redirect the user to the login page in Begin_Request.
However this issue has been reported most commonly on a page which is redirected to immediately after a user has just logged in. So for some reason the user is still being sent a 401 error when they are in fact authenticated. Any idea why this would be?