Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Redirection issues with FireFox in latest IntraWeb version
#1
I am in the process of migrating our main web application from IW 15.2.49 (our current production version) to 16.2.4. When trying to test the web application (built with the latest IW version) with FireFox, I have run into several issues that might be closely related. To the FireFox user, the symptom is that the (next or updated) page never is loaded, you just see the spinner on the (current page) for a long time until it eventually times out with the error message NS_ERROR_NET_EMPTY_RESPONSE . For Chrome and Edge I see no issues. A setting that might be of importance here is that we run with AllowMultipleSessionsPerUser=True (for security reasons, if a tab for a user serssion is closed without making a logout, it should not be possible to reopen the same session).

The first issue is when we apply a security feature on our login page in order to change the response to a redirect when we do a POST when the user has entered senstive information. If I recall correctly it was suggested by you when discussing a finding from a customer penetration test. We call a helper procedure ChangeResponseCodeFromOKToRedirectAndStayInSession which calls another procedure like this:

Code:
ChangeResponseCodeFromOKToRedirect(WebApplication.Request.Referer);

The second procedure looks like this:

Code:
procedure ChangeResponseCodeFromOKToRedirect(const URL: string);
begin
  if (WebApplication.Response.Code < 301) or (WebApplication.Response.Code > 303) then
    WebApplication.Response.Code := 302;
  if WebApplication.Response.Headers.IndexOfName('Location') < 0 then
    WebApplication.Response.AddHeader('Location', URL);
end;

Based on AI suggestions, I changed the response code to 303, which seemed to bypass this first FF issues (and still work in Chrome ande Edge). Is this a sensible modification in your opinion?

The second issue comes in the next step in the login process where we after successful authentication change the session ID (also for security reasons). We do this by calling

Code:
WebApplication.ResetApplicationID;

Again, this was a method added by you as a result of discussing penetration test findings. FF hangs as described above after this is called. I have experimented with workarounds but so far found no other than actually skipping this step when WebApplication.Browser is TFireFox. Do you have a sugegstion for another workaround that would actually change the session ID? Or is this something that should be fixed in the IntraWeb code for an upcoming release?

The third issue is when the user clicks Logout in the menu of our web application. Our code determines a logout page URL (which could be a static HTML page hosted by the web application) and then calls WebApplication.TerminateAndRedirect to this URL. Same issue, FF hangs. Based on AI suggestions, I wrote the following workaround:

Code:
  if WebApplication.Browser is TFireFox then
  begin
    ReportStandardEventToLogCentral(letHint, 'Using ExecuteJS to redirect to the logout page due to Firefox/IW16 issue,'
      + ' session will not actually be terminated until timeout but Logout will be called to finalize our own resources.');
    Logout();
    WebApplication.ExecuteJS('window.location.replace("' + LogoutURL + '")');
  end
  else
    WebApplication.TerminateAndRedirect(LogoutURL);

Is there a better workaround that actually terminates the session immediately? Or should the IntraWeb code for WebApplication.TerminateAndRedirect be fixed?

Best regards

Magnus Oskarsson
Reply
#2
I would like to renew this thread. We upgraded our production SaaS solution to the new migrated version on Sunday, but pretty quickly got reports from customers who were unable to log in. All of these were using Edge, and although not confirmed in all cases it looks like a common factor was that they used Edge for Business. It should be noted that my own Edge also says "Edge for Business" on the about screen but works without these issues, and we see in our logs that there are also a large number of successful login sequences with Edge. So most likely the issues is dependent on which security policies are enforced via Entra. As a temporary workaround we have turned off the security feature for changing sessionID totally (i.e. it is skipped regardless of browser at the moment). This is of course not an acceptable long-term solution for us.

Obviously there is some key difference between the IW versions mentioned above with regards to this, that makes some browsers non-compatible with the web application for the above cases. It would be much appreciated if you could analyse this and come back with an update the solves the issues, or suggest a better workaround than what I have been able to find so far.

A note: For the final case I have modified our code so that the Logout() call is made after rendering of the page is completed, as the above version could give issues on some pages.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)