Glimpse an opensource, is a web debugger and diagnostics tool for ASP.NET and ASP.NET MVC. Glimpse inspects web requests as they happen, providing insights and tooling that reduce debugging time and empower every developer to improve their web applications.
Recently had an issue which was surprising to deal with. An ASP .NET Application issuing a Large POST Data (JSON Format) working when CA Single Sign On (SiteMinder) WebAgent was disabled. However when enabled, the POST request returned a HTTP 500 Error as response.
Finer Details of the Issue being encountered.
BROWSER >> ISAPI FILTER / MODULE (WEBSERVER IIS) >> ASP .NET Code.
We traced both SM Enabled and Disabled Request from BROWSER >> ISAPI FILTER / MODULE (WebServer IIS) using a HTTP Requestor Tool which can generate different types of Request pattern. We took the POST DATA, stuck that into the Tool and did a POST to the same URL (under both Conditions SM Enabled / Disabled).
We see than when SM WebAgent is turned on, we are getting a ASP .Net Error back as response for the request we issued. At the same time when SM WebAgent is turned down we get a successful response from ASP .Net Code. Hence using the tool we were able to go beyond SM trace log (no errors in SM Logs - only success) and inference that the HTTP 500 error is being thrown by ASP .NET Code (This was confirmed).
We then started focusing on why is the ASP .NET application issuing a HTTP 500 Error as response when SM WebAgent is enabled. The obvious suspect was the possibility of SM WebAgent Tampering the POST Data. After enabling code level logging at the ASP .Net layer; we printed out a log file with the incoming POST Data at Code level. We found that with SM WebAgent enabled the file created was empty, however with SM WebAgent disabled the file created was populated with the POST Data.
Further investigation proofed that there was an logging tool called GLIMPSE which was running and that was causing the issue when interworking with SM WebAgent.
- We removed this Tool from the WebSite (SM enabled), the POST worked. We added the Tool back in (SM Enabled) and POST Stopped working.
- We add the Tool into WebSite (SMDISABLED), POST works. We add the Tool into WebSite (SMENABLED), POST stops working.
We knew that GLIMPSE (Reference Link below) had earlier interoperability issues with SiteMinder. However that was mitigated by a configuration change in GLIMPSE. In this case even with this configuration change in place, we were seeing interoperability issues. Hence due to business importance of SiteMinder we removed the tool from the ASP .NET Application.
Reference Link.
#############
1. https://github.com/Glimpse/Glimpse/issues/547
We do have a Support Ticket open on this issue. The reason I blogged here is, currently there seems be no solution within GLIMPSE nor in SiteMinder to have the tool interworking. Hence incase any one happens to see such an anomaly i.e. HTTP 500 errors and nothing being logged in SiteMinder Trace logs except success (You may need to start looking at what else is running other than the Application Code).
Having said that I have channelized the Support ticket to seek thoughts from CA Engineering about why GLIMPSE breaks when SM is enabled or Vice Versa; coz we don't know who is breaking who? Would let know if we find anything.
Regards
Hubert