Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Getting "Invalid page context" exceptions after upgrade to 15.1.12
Hi! We have just upgraded three of our web applications (let's call them A, B, and C) from IW 15.0.15 to 15.1.12, where we make use of some of the new security features. After this, we have started to get EIWSecurityException exceptions with message 'Invalid page context' in our maintenance logs. Most of them are related to two distinct and reproducible cases in application B, but we have so far also seen two cases in application A which as of yet are more difficult to analyze. 

Case 1 (in application B) do you get when you click on a button on a mobile friendly page, built with CGDevTools JQuery Mobile controls. The server side (async) button click event handler looks like this:
procedure TEmIndClientAppAlertActivationWebForm.ActivateButtonJQMButtonOptionsEventsVClick(
  Sender: TObject; AParams: TStringList);
The link still seems to work functionally for the user (in this case it opens up a specific app on the smartphone). The exception log comes a few hundred milliseconds after the button click has been logged (you do not see the logging code above, it is made in a base form just before this method is called). If you look at the call stack, there is nothing from our own code there, just internal IntraWeb stuff.

Case 2 comes from a login page in B which uses only standard IntraWeb controls. When the user clicks the Login button, we generate a redirect response (302) in order to prevent the browser from storing the login credentials in its cache. This is a solution (for a finding in a penetration test) that we developed together with Alexandre a few years ago. What we do in this case is basically the following:
procedure TBaseIndClientLoginWebDialog.LoginButtonClick(Sender: TObject);
  LoginProgressRegion.Visible := True;
  LoginTimer.Enabled := True;
  ReportInformation('Protecting sensitive POST by using a redirect');
  WebApplication.Response.Code := 302;
  WebApplication.Response.AddHeader('Location', WebApplication.Request.Referer);
Again, it still seems to work functionally for the user, but the exception is logged a few hundred milliseconds after the click event. Sometimes it is also followed by a EInvalidAppID exception with message 'Session context is not valid'. What is interesting is that web application A also has a login page with almost identical code, but there you get no error. There is one security related setting that differs between applications A and B. In A we use the following:


together with

AllowMultipleSessionsPerUser=True (which should translate to SessionOptions.UniqueURL=True, right?)

What differs in B (where we get the exceptions) is that we for now are forced to run with SurrogateSessionId=False due to an as of yet unsolved problem with a CGDevTools control.

A note: I tried setting CheckWindowId=False (as this property was added since 15.0.15) for application B but it made no difference. 

Thankful for feedback on this. Is there something that needs to be corrected in IW code, or can we change our code somehow to avoid the problems?

Best regards

Magnus Oskarsson
In such funny situations where I have no idea what might be causing the error, I remove half of the code and then add it one or more lines at a time until the error occurs. At that moment, I try changing half of the variables values associated with the error causing line, in the same way. It is troublesome but often effective.
Invalid Page Context is a direct result of CheckFormId failing. If you disable CheckFormId setting the error should stop occurring.

CheckFormId is internally very simple and there is little margin for a misbehavior. What is basically happening is that IW is receiving parameters to update form controls but the form is not the one expected.

Like, your active form is FormA (meaning WebApplication.ActiveForm = FormA) but the form being displayed in the browser is a different one.

Is it possible?
Hi Alexandre,

sorry for the delay in response, I have unfortunately been out of the office due to illness for a few days. There is definitely something strange in these cases compared to the previous version of IW we used. There are not multiple forms involved in any of the cases which can explain it (you are in both cases still in the start form, and are not (yet) trying to create some other form). Setting SurrogateSessionId=True for app B does not remove the exception in case 2 (which is strange since I do not see any difference then between A and B). But setting CheckFormId=False does as you say remove it, so that can be a temporary workaround too keep our error logs clean. But we do want to run with as high security as possible, so we would still want a solution for this (in the same way as we would want a solution for the CGDevTools issue which forces SurrogateSessionID=False).

I'll check if I can find my old test project for case 2 and see if the error can be easily reproduced.

Best regards

Magnus Oskarsson
Hi again Alexandre!

I found the test application I mentioned (I think I have sent you some previous version(s) of it before). I finally was able to reproduce the exception in case 2. The key is to start a session with one or more parameters in the URL, e.g.$/start/?param1=value1

Then you will get the error if you click the Login button. I have attached the test application. 

Note: Application B is always started with parameters in the URL, which explains the difference with application A (which is usually not).

I have not yet been able to reproduce case 1, but I am guessing it is something similar (an internal redirect?).

Best regards

Magnus Oskarsson

Attached Files
.zip (Size: 5.05 KB / Downloads: 3)
Hi again. Just wanted to mention that I will be out of the office again for much of next week, so a reply from me could be delayed several days or even a week. I could also mention that I tried calling WebApplication.RunParams.Clear() in FormCreate (after reading the run-params). This gets rid of them in the browser bar but does not help against this problem.

Also, our maintenance logs has now shown a few more places where we get the same error. All these involve url parameters, but are not using the explicit redirect that we use in the test program (that duplicates case 2). 

Best regards

Magnus Oskarsson
Hi Alexandre, I'm back at the office again. Any news on this one? The test application with a reproducible error is in a previous post above.

Best regards

Magnus Oskarsson
Hi Magnus,

yes, I can recreate it using your demo application, thank you for that.

I'm still working on the fix but should have some news soon.
Thanks Alexandre,

just wanted to mention again that we have seen several more cases where this happens besides the one I could reproduce in the test program (the one with the explicit redirect), and many (but not all) involve url parameters for the start form. For example, we have four almost identical cases in a mobile web application (built with CGDevTools jQuery Mobile components) where it looks from the logs that two almost simultaneous sessions are created for the same user agent and IP (happened both with Chrome Mobile and Safari Mobile). In this case no url parameters should be involved. Also, I see some cases in our main web application (pure standard IW) where it looks (from logs) like the loading of the start page fails somehow and you get the exception many seconds later (possible as a result of a refresh). Let me know if you need more details on this, or if you are on to something that might explain all errors that have occurred after the upgrade.

EDIT: Note: If you can find a fix it would be great if the next release (15.1.15?) would still be binary compatible with 15.1.12 (as it is currently difficult to get updated CGDevTools installers).

Best regards

Magnus Oskarsson
Hi Magnus,

We have a fix in place and it is being tested. I believe it will resolve the "Invalid page context" errors in all cases.

Regarding the 2 sessions from mobile browsers... It seems that some mobile devices repost some requests if they don't receive a response within a short time range. It shouldn't cause problems unless there is something else going on.

Forum Jump:

Users browsing this thread: 1 Guest(s)