I've been troubleshooting this one off and on for the past week. I've got a site using relying party MVC code from the DotNetOpenAuth project. I've been using this since 2009.
Recently, the Google logins have been failing. I'd say about 80% of the time the Google login works fine. So the intermittent nature makes this hard to diagnose.
Here's what I've tried:
Of course I've verified that the openid_identifier is using the correct URL ( https://www.google.com/accounts/o8/id )
I've updated to the latest release (DotNetOpenAuth 3.4).
I've tried adding default proxy settings as per this answer.
I've extended the timeout settings and even reduced memory on SQL to give IIS more RAM as this answer suggests.
I've added logging to every request and error to see if I could get any valuable information. This doesn't tell me much.
I've watched the requests/responses with Fiddler to see if I could spot anything.
I've tested my Google login on StackOverflow a number of times on the off chance that this is actually a problem with Google. And it's been working every time so far.
Any ideas?
UPDATE
In effort to pinpoint the problem I changed the code on my site a bit. Rather than doing this all on one line...
openid.CreateRequest(Request.Form["openid_identifier"]).RedirectingResponse.AsActionResult();
I broke it up into sections with logging in between...
MvcApplication.Logger.Info("Loading... " + Request.Form["openid_identifier"]);
var request = openid.CreateRequest(Request.Form["openid_identifier"]);
var redirect = request.RedirectingResponse;
MvcApplication.Logger.Info("Status... " + redirect.Status);
if (redirect.Status.ToString().ToLower() != "found")
{
MvcApplication.Logger.Error("Details... " + redirect.Body);
}
return redirect.AsActionResult();
So I'll be waiting for the next error.
I figured it out. This was being caused by New Relic. I'm not sure exactly how (or why it was intermittent) but that's what it was. New Relic automatically instruments your pages in certain ways so maybe it interfered with the request to the OpenID provider.
I looked back at the timeframe in which this all started and found that it was right around the time I installed New Relic on the server. So I uninstalled it, restarted IIS, and let the site go for 48 hours without it. I didn't get a single error in that time. So a couple hours ago I reinstalled it and sure enough I was able to duplicate the problem.
Anyway, I've removed New Relic again and all is good. I'll notify them about this.
Related
I promise I searched for the answer...
My application consist of both a Mobile backend in azure and a Web-client application that makes calls upon this back-end.
I have run across a bizarre bug that creates 404 not found errors when calling a Http Get function on my backend.
The bizarre part of this issue is that the error is random. It is probably a %50 chance that I might get a 404 or a 200 ok response from the server. This only happens on one specific method that was recently added.
I am wondering if breaking the back-end into instances might have created a non-identical copy of my app.
I removed the instance, and the specific api I have been calling is not longer available on the published version it is visible while running on debug.. I get 100% error on the published version now.
What is wrong with azure? cleaning and rebuilding the back-end does nothing.
[Route("api/UserProject/{projectId}")]
[HttpGet]
public HttpResponseMessage GetUserProjectByProjectId(int projectId)
{
//Get all UserProject
List<DTO.User> userList = new List<DTO.User>();
DataTable UserdataTable = SqlHelper.ExecuteDataset("dbo.UserGetByProjectId", projectId).Tables[0];
if (UserdataTable.Rows.Count > 0)
{
foreach (DataRow dataRow in UserdataTable.Rows)
{
DTO.User u = new DTO.User();
Map.DataToObject(dataRow, u);
userList.Add(u);
}
}
return this.Request.CreateResponse(HttpStatusCode.OK, userList);
}
going to the api/help page on Debug the UserProject route works and is shown in DEBUG mode, but as soon as I publish the app the UserProject function is not longer anywhere to be found.
Wow I finally fixed it. I did the one thing I though would be useless and it worked.
I restarted the service from the azure portal....
My opinion: I guess the created intances where the ones working of the latest version while the original was unable to be updated and the only way to make the original update was to restart the whole thing.
I really don't know why this happened, if you guys want to comment on this please do so.
I apologize for how open ended I'm sure this will end up. I'll try to break this up in manageable chunks.
I'm writing a program that deals with SCCM. This program is locked down by security groups.
If you are not a member of the 'Server Operators' group, you don't get in. Simple. I've been testing for awhile on my dev machine (a Dell that is on wireless) with no issues.
When I released a beta, I found that under certain circumstances the program will not pick up on the user's security group membership and therefore deny access.
I was able to reproduce the issue, it seems machines on wireless tend to have this issue. Though, it's more complicated than that.
-Freshly imaged machines seem to have this issue
-Not all wireless machines; my dev machine is wireless
-One desktop (no wireless) has this issue. (It's at a remote site, so I can't really pick that one apart) I think it's a fresh image as well. I did however test on another computer at the same site - worked fine.
-Connecting to ethernet seems to have an effect - 75% of the time it fixes the issue somehow - after a bit of a wait. (Works on both ethernet and wireless at that point)
I've been trying to get a breakpoint set on one of these machines so I can see what is going on. Problem is, by the time I get VS.net installed the problem solves itself. I know (very little) about remote debugging - currently looking into that. This scenario makes me wonder if it's update related (the image is fairly up to date, maybe a month or two out?)
I also wrote a small utility that tests the login procedure (using the same code) and it finds the security group every time. Wat.
Code for finding security group of a user:
(courtesy of Stack :) )
static bool IsUserMemberOf_(string user, string group)
{ // (I realize the user parameter is superfluous in this case)
try
{
DirectoryEntry entry = new DirectoryEntry("LDAP://" + TC.act_Domain, TC.act_AD_User, TC.enc_GetADPassword());
DirectorySearcher mySearcher = new DirectorySearcher(entry);
mySearcher.Filter = "(&(objectClass=user)(|(cn=" + TC.act_AD_User + ")(sAMAccountName=" + TC.act_AD_User + ")))";
SearchResult result = mySearcher.FindOne();
foreach (string GroupPath in result.Properties["memberOf"])
{
if (GroupPath.Contains(group))
{
return true;
}
}
}
catch (DirectoryServicesCOMException)
{
}
return false;
}
I've also tried another method (using Principal.IsMemberOf() ), which had the same result. I've also investigated DNS/Network problems. Not ruling it out, but doesn't seem to be a factor in the testing I've done.
I'm at a loss. If anyone has any thoughts, by all means please lay them on me.
Thanks
Yeah, it was the .net version. Our image starts with .net 4.0. Throwing 4.5.2 at it clears it right up. I would have expected an error at runtime, but I guess not.
... I'll show myself out
Ok, I got an asp.net web service using WSE2. It runs on a xp machine.
And I got the front end asp.net application in my win7 machine.
both in Framework 3.5.
In production environnement everthing is fine.
The problem is, when I run the "developpement" version of the front end, web services calls takes forever. And by forever, I mean eternity. Here we count eternity in minutes.
By "developpement" version, I mean that I run the instance that is bound to the visual studion (2008) solution. I use the local IIS web server.
My first thought was for a network/firewall problem between my two machines. But if, form visual studio, I "publish" the site to another virtual folder, then everithing works fine.
So I have http://localhost/MyDevApp and http://localhost/MyPublishedApp.
Both uses default app pool. Both have identical web.config. As far as I know, both virtual directories have exact same parameters.
But http://localhost/MyDevApp is terribly when calling web services, and http://localhost/MyPublishedApp runs at light's speed.
It is like this since 3 days now.
Doing some debuggin I can say that :
MyWebServiceRequest request = new MyWebServiceRequest ();
request.Url = "http://mywebserviceurl";
request.RequestSoapContext.Tokes.Add (MyUsernameToken);
//All these previous lines executes correctly, rapidly.
//THIS is the slow one.
request.CallWebServiceMethod ();
Does anyone have the slightest idea what the problem can be?
Edit
I also tried changing the virtual directory from my web site's property to something different (say http://localhost/MydDevApp2), with the same result.
Edit 2
Maybe it can be in cause, the site binded to the solution reside in c:\Projets\MySolution\MyDevApp while the "published" one is under c:\inetpub\wwwroot\MyPublishedApp. The c:\Projets folder is excluded from the antivirus scans, so normally it should be faster rather than slower.
Edit 3
I created another workspace (the solution is under team server source control) in c:\inetpub\wwwroot\Other, changed the url of the web project, compiled and run : no problem. So it really seems that the physical path where the files resides is causing this, while the fact of beeing bound to the solution is not.
Edit 4 (August 19)
Well, it seems that there not much to do. It's been about 10 days since my last update, and now the site under the new workspace is beginning to slow down too. So I moved the workspace on disk, now in c:\inetpub\wwwroot\Other2, and you know what? That's running fine again. Perhaps I will have to move it again in about 10 days.
Edit 5
I flagged my question to move to serverfault, finally it does not have nothing to do with programmation, as I first thought.
Hard to say without seeing your machine in config, but often times it means you have some kind of a problem with your dns server or hosts file that is causing the process to be slow to resolve the service.
Also, if you are using a proxy server, make sure you are bypassing it for any urls that call the service.
Finally, it appears that wse2 traces where on :
<microsoft.web.services2>
<diagnostics>
<trace enabled="true" input="InputTrace.log" output="OutputTrace.log" />
</diagnostics>
<policy>
<cache name="policyCache.config" />
</policy>
</microsoft.web.services2>
While the log file was growing more and more, it slow down and down... just disabling the trace solves the problem.
Really weird problem, I have just moved all our sites to a new Win2008 64bit server with IIS7 (Was on a Win2003 IIS6) and have started having problems with PayPal Pro / PayFlow.
A few of these websites are stores with SSL's and use PayPal Pro to process the payment - Since the move, intermittently I am getting errors like.
msxml3.dll error '800c0005' The
system cannot locate the resource
specified.
Where it seems I cannot connect resolve the PayPal URL to post the data to, as I say this has only started happening since we are on this new server. And what is even more annoying is that its completely intermittent!! Works fine for hours then will throw this error over and over then will be fine again, it effects both the Classic ASP and ASP.NET C# sites using PayPal??
Here is a log file entry if that helps?
2010-07-05 11:34:07 80.100.200.155
POST /scripts/60_Pay.asp
|297|800c0005|The_system_cannot_locate_the_resource_specified.__
443 - 92.8.25.196
Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+6.0;+WOW64;+Sky+Broadband;+GTB6.5;+SLCC1;+.NET+CLR+2.0.50727;+Media+Center+PC+5.0;+.NET+CLR+3.5.21022;+.NET+CLR+3.5.30729;+MDDC;+.NET+CLR+3.0.30729)
500 0 0 1907
Anyone have any ideas on what could be causing this? I was wondering if there was a way to increase the length of time it will wait to try and resolve from the external URL?
Any help would be GREATLY appreciated
Try setting the application pool that you are running this under to run in 32 bit mode and restart IIS. This will at least remove one variable.
Next you should check to see if you can write a very simple asp page that instantiates the xmlhttp object and tries to load a URL to make sure you don't have a network configuration that is preventing the new machine from reaching PayPal's servers (but which allowed the old machine to do so). This could be on your side, or their side.
Finally, are you able to run the code under a debugger on the server so you can figure out what line the error is happening on?
The title pretty much says it all. Some caveats are:
I need to be able to do it in C#
It needs to be able to be done from a remote server (ie, running on one server, checking IIS on another)
Needs to be close to real-time (within 1 second)
Can use WMI calls
I've tried watching the log file, but it turns out that isn't nearly close enough to real-time.
Thanks!
EDIT: I put this in a comment on Tom's answer, but it's more visible here:
I was able to look for changes using this counter:
var perf = new PerformanceCounter("ASP.NET Apps v2.0.50727", "Requests Total", "_LM_W3SVC_[IIS-Site-ID]_ROOT", "[Server-Name]");
How about reading the ASP.NET requests/sec performance counter on the remote machine?
The System.Diagnostics.PerformanceCounter class has a constructor which takes a machine name.