01-18-2023, 03:36 PM
Hi again, I did some tests with F12 developer tools, changing FormID and then refreshing, and yes, it was easy to reproduce 'Invalid page context' errors this way. I have tested adding the following to our code to avoid call stacks being generated for this error:
This seems to work and in the tests with developer tools, the page recovered nicely and "silently" after such a case. But I want to make sure this only affects logging, and does not introduce any security risks?
I deployed a version to the production server a couple of days ago with this version plus some fixed memory leaks in our own code, but I have to wait longer to see if it had any effect (since the web application was restarted which I believe will postpone the error state in the system). I still see the effect of a 50 MB jump in memory when an exception occurs (this time it was a previously unseen exception in our own code). Possibly the memory jump comes only for the first exception thrown and handled since the web application was started, but I cannot say that for certain without putting a lot of time into analyzing logs.
Code:
ExceptionLogger.RegisterIgnoreException(EIWSecurityException);This seems to work and in the tests with developer tools, the page recovered nicely and "silently" after such a case. But I want to make sure this only affects logging, and does not introduce any security risks?
I deployed a version to the production server a couple of days ago with this version plus some fixed memory leaks in our own code, but I have to wait longer to see if it had any effect (since the web application was restarted which I believe will postpone the error state in the system). I still see the effect of a 50 MB jump in memory when an exception occurs (this time it was a previously unseen exception in our own code). Possibly the memory jump comes only for the first exception thrown and handled since the web application was started, but I cannot say that for certain without putting a lot of time into analyzing logs.