I'm using HttpWebRequest to pull down XML, and POST data back to a 'WebService' and getting a 401 on the POST.
When creating the requests I've added Credentials and now tried a credentials cache and setting PreAutenticate to True, still getting the 401! :(
Watching the HTTP traffic on the router I set the get make an unauthenticated GET request.. it hits the 401 and then makes an authenticated GET and is allowed through. When I watch the POST I see it hit the 401... and it doesn't even try an authenticated POST.
This appears only on mobile phones (compact-framework 3.5 and 2.0 on WinMobile 6.1). The same .exe works perfectly on any desktop machines.
What am I missing? Please help!
Try setting the header manually:
http://devproj20.blogspot.com/2008/02/assigning-basic-authorization-http.html
Related
I have an application that generates a web request to Facebook Graph API to get a share count from an external page. I have been using this code for over a year without issue, and suddenly, the share count is not working when the request is made from .NET. However, if I make the request from a web browser, it works just fine. My code is as follows:
string fbLink = "https://graph.facebook.com/?id=" + externalLink + "&fields=og_object%7Bengagement%7D&access_token=<token_removed>";
WebClient client = new WebClient();
string fbString = client.DownloadString(fbLink);
This code still appears to be working fine, in that the request is made, and FB responds with no errors. In fact, it responds back with correct page id, and details. However, the share count is zero.
Here is where it gets a little bit weird. On my localhost development machine, the code works fine and returns the proper share count. However, if I run the code on my actual server (an AWS EC2 instance), the share count shows zero.
If I open Chrome and run the request from the browser, the share count displays as expected.
If I open Internet Explorer 11, and run the request from the browser, the counter shows zero. HOWEVER, if I log in to Facebook from IE11, and then run the request to FB Graph API, the response shows the correct page count.
This is very confusing to me, as it appears the reason the counter has stopped working, has to do with cookies, or maybe the browser being logged into FB. This should not be the case as I am using an APP token ID, and I wouldn't expect to need to be logged into FB in order to make a request to Graph API.
Does anybody have any ideas why my request/code in .NET worked just fine for a year and a half, and just stopped working? Or why the requests work fine on my localhost and not my live server?
After spending considerable time on this issue, I have fixed the issue. There is a FB authentication cookie that was being transmitted through a web browser query. The cookie name was "XS" and the value was a long string that is used as a sessionId for my specific login. If I created this cookie in my web request in C# code, I get the proper response with correct # of shares.
WebClient client = new WebClient();
client.Headers.Add("Cookie", "xs=<removed>;");
I have no idea why I have to do this, only on my EC2 server. Nowhere in FB's documentation does it say you have to spoof a valid logged in authentication string cookie in order to obtain correct Share Count results from a request to it's Graph API, but there you have it. A workaround at least.
I'm working on an application allowing users to sign in and register using Google and Yahoo through OpenID using ASP.NET MVC4, and the DotNetOpenAuth library. Google is working fine, and Yahoo was working fine for a few months as well until a few days ago.
For some reason, using my local version of IE 11, after authenticating with Yahoo, two responses are sent back to the web server, and each is validated in its own separate thread. One response is determined to be valid, and the other response is determined to be invalid because the first response is already validated. The responses are then sent back to the user, and depending on which one is sent first, two very different outcomes can occur.
Using Chrome and Firefox works correctly. Yahoo is returning only one response. Using different versions of IE on other machines (including 11) work correctly as well. Using fiddler, I've verified that the correct requests are being sent out. I've tried clearing my cache, disabling any addons, and changing document and browser modes using the dev tools, and no luck. Is there anything that can be causing two responses to be sent back?
The basic code to send the request is below. The config file is using all default values.
OpenIdRelyingParty openid = new OpenIdRelyingParty();
IAuthenticationRequest request = openid.CreateRequest(Identifier.Parse("https://me.yahoo.com"));
var fields = new ClaimsRequest();
fields.Email = DemandLevel.Require;
request.AddExtension(fields);
return request.RedirectingResponse.AsActionResult();
It turns out that the problem was that I was sending a request to tell Yahoo to redirect back to an unencrypted connection after authentication. If I tell Yahoo to return to an https url, rather than http, everything works correctly, and I only get one request coming back to the application.
I have a C# app to log on a website and collects some data. The server (Apache) sometimes sends back the 302 code whereupon the C# application sends a request again to the server with the same URI. The problem is the Apache stops with 'W' status (HttpClient stuck on request).
I would like to know if I send a request with the response.ResponseURI that it would be solve this problem, and why the server sends the code 302 so on erratic way? Someone said me the Apache answers this code (302) when the content of the requested page was not changed. ???
Help me, please?
Check http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html . If you have a 302 code response you should redo a request with the URI indicated by the Location: header of the HTTP server response.
This is a temporary redirect.
Redirect are quite common in response to POST requests (to be perfect it should be a 303 redirect...) and it's quite certainly done to redirect you to the home page url for logged in users OR to the login form if you failed your login.
I´m getting a problem sending the authentication request with activated attribute exchange. It works with FF and Opera but IE seems to have a problem with it.
The error occurs within the request.RedirectToProvider(). The Url within the address bar shows the endpoints url.
Here is a code snippet where the authentication request is created and sent
using (OpenIdRelyingParty openid = this.createRelyingParty())
{
IAuthenticationRequest request = openid.CreateRequest(openid_identifier, realm);
;
var fetch = new FetchRequest();
fetch.Attributes.AddRequired(WellKnownAttributes.Contact.Email);
request.AddExtension(fetch);
// Send your visitor to their Provider for authentication.
request.RedirectToProvider();
}
I guess that inside RedirectToProvider() a POST is sent and short after a GET. By RFC a POST followed by a GET is not allowed. Unfortunately I don`t know how to validate it.
Does someone got the same problem?
On further investigation this seems to happen (based upon the providers logs):
The authentication request is sent via POST. The Provider answers with a redirect. This is how it happens that there is at first a POST and then a GET.
I dont think this is how the openId specification say to do it. Shouldnt there be a POST response if i request with a POST and a GET if I request with a GET?
Anyhow.. Is there a way to make the RedirectToProvider()-method sending the request via GET instead of POST?
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>