Project

General

Profile

Actions

Bug #13308

open

Back Broken w/ SAML

Added by Aaron Wright 21 days ago. Updated 21 days ago.

Status:
InProgress
Priority:
Normal
Target version:
Start date:
12/09/2024
Due date:
% Done:

0%

Estimated time:

Description

I have a single page application using internal paths and SAML for authentication. The SAML authentication works great and end up at my landing page as expected. When I click on a sub-page everything works fine. But when I navigate back, the page doesn't change.

I get this error in the JavaScript console when navigating back:

?wtd=Nn8DKBBvIyRPDLeg&sid=1074320452&scrW=1920&scrH=1200&tz=-480&tzS=America%2FLos_Angeles&htmlHistory=true&deployPath=%2F&request=script&rand=2159790336:18  Uncaught TypeError: Cannot read properties of undefined (reading 'length')
    at onHashChange (?wtd=Nn8DKBBvIyRPDLeg&sid=1074320452&scrW=1920&scrH=1200&tz=-480&tzS=America%2FLos_Angeles&htmlHistory=true&deployPath=%2F&request=script&rand=2159790336:18:13615)
    at ?wtd=Nn8DKBBvIyRPDLeg&sid=1074320452&scrW=1920&scrH=1200&tz=-480&tzS=America%2FLos_Angeles&htmlHistory=true&deployPath=%2F&request=script&rand=2159790336:18:12119
onHashChange @ ?wtd=Nn8DKBBvIyRPDLeg&sid=1074320452&scrW=1920&scrH=1200&tz=-480&tzS=America%2FLos_Angeles&htmlHistory=true&deployPath=%2F&request=script&rand=2159790336:18
(anonymous) @ ?wtd=Nn8DKBBvIyRPDLeg&sid=1074320452&scrW=1920&scrH=1200&tz=-480&tzS=America%2FLos_Angeles&htmlHistory=true&deployPath=%2F&request=script&rand=2159790336:18

This is where the error comes from:

In this situation, e, or rather history's current state, is undefined.

It appears that, in JavaScript, null !== is not sufficient to check for undefined. I didn't dig into it much, but I see null !== used in quite a few places in Wt, so I assume history's current state is supposed to be assigned somewhere but SAML messes with that assignment. I do not see this problem if I disable SAML. I also do not see this problem if I use a link to go back to the landing page, then click on a sub-page and navigate back. It appears that by that point history's current state is sufficiently initialized.

My current fix for this is to use null !=, which checks for null and undefined in JavaScript:

diff --git a/src/web/skeleton/Wt.js b/src/web/skeleton/Wt.js
index 817742e..b2ed40b 100644
--- a/src/web/skeleton/Wt.js
+++ b/src/web/skeleton/Wt.js
@@ -2289,7 +2289,7 @@ window._$_APP_CLASS_$_ = new (function() {
     const newLocation = _$_WT_CLASS_$_.history.getCurrentState();

     if (
-      newLocation !== null &&
+      newLocation != null &&
       newLocation.length > 0 &&
       !newLocation.startsWith("/")
     ) {

I don't feel like this is the correct long-term solution, but it works for now.

I'm using Wt version 4.11.0.


Files

clipboard-202412090740-d1uzj.png (12.4 KB) clipboard-202412090740-d1uzj.png Aaron Wright, 12/09/2024 04:40 PM
Actions #1

Updated by Matthias Van Ceulebroeck 21 days ago

  • Status changed from New to InProgress
  • Assignee set to Matthias Van Ceulebroeck
  • Target version set to 4.11.2

Hey Aaron,

thanks for the report! Internally we had found a bug very similar to this too, and this was implemented in #13300.
I'll take a look whether this also resolves your issue. I think it's very much related (same root cause, namely null == undefined being true and null === undefined being false), but potentially slightly different causes.

I'll likely have an update for this tomorrow.

Best,
Matthias

Actions

Also available in: Atom PDF