There is already a StackOverflow post that has addressed this issue. However, it couldn't help me.
So, I have written an OpenID login implementation using DotNetOpenAuth and I keep on getting "Message signature was incorrect".
The funny thing is that this is happening from a PC I have at my home. At my work I'm not getting this error and it is working ok.
I've tried to add in the web.config
<trust level="Full" />
<httpRuntime maxQueryStringLength="20000" />
Also, I've added the null parameter while instantiating the OpenIdRelyingParty
new OpenIdRelyingParty(null)
Lastly, I've opened the 443 port in the router and PC.
The key factor is that this is not working from the PC I have at home. However, it is working from the PC I have at work. Both have the same exact code.
When you make a request to an OAuth provider, the framework generates a signature. This signature is a hash of different values, including the URL that you are requesting. The provider then does the same and performs a comparison. If the hash that the provider builds is not the same as the one you've provided via the oauth_signature query string parameter, the request is not considered valid, and you get this error.
I ran into a similar issue when my client application was signing an URL that was something along the lines of api.foo.com/oauth. The server had an URL rewriter that rewrote the URL to foo.com/api/oauth before the provider had a chance to process anything. Since the client URL and the URL that was processed by the provider were different, this caused different signatures, hence the error.
Check your computer clock. The time should be correct as well as the timezone.
If that doesn't help it, please activate logging and see if it gives you more details about why the signature is wrong.
Related
We got the following problem:
I am currently developing a web server implementing a specific API. The association behind that API provided specific test cases I'm using to test my implementation.
One of the test cases is:
5.3.2.12 Robustness, large resource ID
This test confirms correct error handling when sending a HTTP request with a very long location ID as URL parameter.
The url its calling looks something like this:
https://localhost:443/api/v2/functions/be13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005ebe13789-1f1e-47d0-8f8a-000000000005
Basically the tests checks, if my server responds with the correct error code if the URL is too long. (At the time of writing it is testing for Errorcode 405, but I already asked them if it shouldn't be 414)
I'm developing the server in Asp.Net 6 and it always returns Bad Request 400 in the testcase.
I don't seem to find a place to change the handling for this behaviour and I am not even sure, if I can, or if the IIS is blocking the request even before it reaches my server. I activated logging in IIS, but the request does not show in the logfile in inetpub/logs/LogFiles.
My question would be, if it is possible to tell IIS to return a different error code in this case, or if it is even possible to handle the error in my application.
What I tried:
Activating IIS Logs to see if the request is even passed to my site. (It did not)
Tried adding Filters to my Controller to see if I can catch an Exception
Checked, if Development Error Sites are called.
Breakpoints in existing middlewares are not reached.
EDIT:
I am now pretty sure now, that the request never reaches my application.
It is possible to reproduce the error by using the default site the IIS generates on windows. Just copy the whole path from above into a browser with the host http://localhost will also just produce the error 400
EDIT 2:
As #YurongDai pointed out, I tried activating failed request tracing for my IIS Site. I used the default path \logs\FailedReqLogFiles.
The folder was created, but no file is written, when I'm opening the URL above in my browser.
IIS Error 400 occurs when the server is unable to process a request sent to a web server. The most common cause of Bad Request error 400 is an invalid URL, but it can happen for other reasons as well. To resolve IIS Error 400, first make sure that you have entered the URL correctly, typos or disallowed characters in the URL are the most common causes of Bad Request errors. If the error persists after verifying the URL, please clear your browser's cache, DNS cache, and cookies and try again.
Clear your browser's cookies.
Clear your browser's cache.
Clear your DNS cache.(Execute the following command in the command prompt window: ipconfig /flushdns)
I have a problem authenticating my user against Active Directory. I am trying to authenticate my user via PrincipalContext.
My issue is that when user password contains non-ASCII character validation fails even with the correct credentials. But I have this problem only on my prod environment. It works just fine on UAT and development environments.
How can I resolve this issue? Is there any setting for AD has anything to do with this?
try to change the password encoding to UTF-8
It is a shot in the dark, but hear me out. This is why I asked if this was a web project. I had a similar problem with identical symptoms. A user came to me saying he couldn't login in my website. Turns out he had "special" characters in his password. It didn't make sense, but after disabling custom errors I realized the error was due to ASP.NET Request Validation: http://msdn.microsoft.com/en-us/library/hh882339%28v=vs.100%29.aspx
Request validation is a feature in ASP.NET that examines an HTTP
request and determines whether it contains potentially dangerous
content. In this context, potentially dangerous content is any HTML
markup or JavaScript code in the body, header, query string, or
cookies of the request. ASP.NET performs this check because markup or
code found in the URL query string, cookies, or posted form values
might have been added to the request for malicious purposes.
Pretty much everything that looked like a tag got flagged and runtime threw an exception way before my code had a chance to validate user's password.
Hope this helps!
So I have created a custom token, based mostly from the MSDN example (http://msdn.microsoft.com/en-us/library/ms731872.aspx) but I can't seem to get it to work. I always get this error " security token with the 'Basic' attachment mode must be signed." in the logs. I have been over the code base several times and
A) obviously it compiles and runs
B) I can't see where the issue is.
The log message isn't all that helpful. I thought it might be something with the cert but I have beat that to death and created a couple different certs (one using server name set to localhost etc...).
A Google search for this turns up almost nothing.
Anyone got a clue what this is, or just tell me where I can maybe look? Like I said - I have been through this code many times, I see the authorization policy get created and all that good stuff, I can see the certificate is set, I just don't know where else to look, I really don't have any code to post, there are so many classes you have to implement. If someone has an idea of what maybe I can look at I will be happy to post that particular class / code snippet.
Thanks
See here: http://social.msdn.microsoft.com/forums/en-us/wcf/thread/F822CCB9-A8A1-474F-87AF-E5CD9EC34494
... wasn't copying the "id" property of the security token correctly.
This was causing a new ID to get created for the security token on the server, which no longer matched the security signature data, and so the message would be rejected.
In your implementation of your custom WSSecurityTokenSerializer to serialize your security token, you probably aren't copying the Id property of the token. The ID needs to match from the client to the server.
A common mistake (one that I'm sure I've made too) is to just id = Guid.NewGuid().ToString() in the constructor. That is fine for its initial creation on the clinet, but when it deserializes on the server, it needs to use the same ID from the client, not a new guid again.
I have a website with digest authentication required and when I browse it with IE8, it gives me 401 even the password is correct. Firefox and Chrome works correctly. I checked the authorization headers with Fiddler, everything seems fine. Can you give me any hints on the problem?
p.s. Additionally I do have the same problem with implementing digest authentication in C#, I don't know these two are related.
I was facing this problem and this was the only mention of it on the net. In Digest Access Authentication the sequence of events that take place is.
GET on /url
401 with a WWW-Authenticate header
This pops up the login dialog on your browser. After you enter your credentials.
GET on /url along with the Authorization header.
200 OK (If everything goes well).
This works fine for Firefox and Chrome but was not working fully for IE8.
By fully I mean, that if I did a GET on a virtual location on the server it worked, but it did not work when I did a GET on a static file. In the case for a static file I was prompted for a login again and again.
After using a sniffer I found out that in the case of requesting a virtual location the sequence of events happened as mentioned above, but when I requested a static file the sequence was as follows:
GET on /url
401 with a WWW-Authenticate header
This pops up the login dialog on your browser. After you enter your credentials.
GET on /url (WITHOUT THE Authorization header)
401 Un-Authorized.
Basically when it was a static file, it took the username and password but never sent it across in the Authorization header. Server not getting this header responded with 401 which again prompted the login.
To make IE8 work properly you have to fool it in thinking that this is not a static file, but is a virtual location. For me, it was easy as I had access the server's source code. I really don't know how to do it, if you don't have access to it.
If you have requested a virtual location.
1. GET /virtual_location
2. 401 with WWW-Authenticate header which will look something like
WWW-Authenticate: Digest realm="validusers#robapi.abb", domain="127.0.0.1:80", qop="auth", nonce="9001cd8a528157344c6373810637d030", opaque="", algorithm="MD5", stale="FALSE"
Notice the opapue parameter is an empty string.
On the other hand if you requested a static-file
1. GET /staticfile.txt
2. 401 with WWW-Authenticate header which will look something like
WWW-Authenticate: Digest realm="validusers#robapi.abb", domain="127.0.0.1:80", qop="auth", nonce="81bd1ca10ed6314570b7362484f0fd31", opaque="0-1c5-4f7f4c1e", algorithm="MD5", stale="FALSE"
Here the opaque parameter is a non empty string.
Hence, if you an ensure that the opaque parameter is always an empty string, IE8 will consider it as a virtual location and the request will go through normally. Since I had access to the the server's code I was able to do this.
Hope this is of any help.
Regards,
Satya Sidhu
I had the same problem. In my case, I was requiring digest authentication for my entire site, using directives in either "<Directory />" or "<Location />". Either way works for Firefox and Safari on Mac, PC, and iOS. Unfortunately, IE8 seems to have trouble with this. After trying several other changes, I finally found that if I only require authentication on a subdirectory (e.g. "<Location /private>"), and move my content into the protected directory, IE8 started working. I went back and forth a few times, changing only this attribute, to confirm that this is the critical difference.
Incidentally, it's worth noting that a tcpdump showed that IE8 wasn't even trying to send a digest authentication. It presented the auth dialog box, took my username and password, then sent a normal GET request with no authentication info.
Are (were) you protecting the entire content tree?
I'm not sure why IE8 (and only IE8) cares about this distinction, but this is what I found.
In searching for a solution to the problem, yours was the only mention that seemed relevant, and I could find no answer posted on the net. This leads me to believe that either no one tries to configure Digest authentication in this way, or most people just give up and use Firefox (or some other non-MS browser)
Wow, I'm definitely having the same problem. I have two virtual hosts, both using digest authentication. On one site I am trying to protect the entire site (i.e. ) and it works in all browsers I have tried except IE8. On the other site, I'm only protecting a subdirectory, and that works fine in IE8.
I had the same problem and tried to use the digest authentication for the whole vhost. But the following configuration did not work on IE.
<Location />
AuthType Digest
AuthName "Login"
AuthDigestDomain /
AuthUserFile /path/to/.htdigest
Require valid-user
</Location>
The workaround in http://lists.centos.org/pipermail/centos/2013-January/131225.html worked well:
ErrorDocument 401 "some random text"
A better solution is to exclude the apache error pages that are normally located at /error/.*
e.g.
Alias /error/ "/usr/share/apache2/error/"
The following configuration worked well for me (see also https://bz.apache.org/bugzilla/show_bug.cgi?id=10932#c5):
<LocationMatch "^/(?!error/)">
AuthType Digest
AuthName "Login"
AuthDigestDomain /
AuthUserFile /path/to/.htdigest
Require valid-user
</LocationMatch>
I created a simple page using the code provided by this page (the first sample):
http://www.dotnetopenauth.net/developers/code-snippets/programmatic-openid-relying-party/
But I can't seem to get it to work, I can redirect to the provider but when the provider redirects back to my page, I get error 500, "The request was rejected by the HTTP filter".
I already checked ISAPI filters which I have none.
I've never seen that error before. Is this page hosted by the Visual Studio Personal Web Server (Casini) or IIS? I suspect you have an HTTP filter installed in IIS (or perhaps your web.config file) that is rejecting the incoming message for some reason.
Note that you need to turn off ASP.NET's default page request validation on any page that can receive an OpenID authentication response because those responses can include character sequences that look like HTML/Javascript-injection attacks but in fact is harmless.
I discovered that I'm using Isa in the server, so I just followed this instructions to get it working.
http://blog.brianfarnhill.com/2009/02/19/sharepoint-gets-the-error-the-request-was-rejected-by-the-http-filter/