Export is null on certain conditions

[bzbzh]

For certain SAML traces it occured to me than the export return an empty file (in fact a file with "null" inside).

An error raises here:

const createFromJSON = function(obj) {
      let stringified = JSON.stringify(obj);
      return JSON.parse(stringified);
    };

    const enrichWithResponse = (req, res) => {
      let responseCopy = createFromJSON(res);
      req.responseStatus = responseCopy.statusCode;
      req.responseStatusText = responseCopy.statusLine;
      req.responseHeaders = responseCopy.responseHeaders;
    };

    let reqscopy = reqs.map(req => {
      let newRequest = createFromJSON(req);
      enrichWithResponse(newRequest, req.getResponse());

      the_filters.forEach(filter => filter(newRequest));
      return newRequest;
    });

When trying to stringify "req.getResponse()" when it returns null.

I wonder if it would be a good solution to alter this:

  'attachHeadersToRequest' : function(request) { // onBeforeSendHeaders
    let uniqueRequestId = new SAMLTrace.UniqueRequestId(request.requestId, request.method, request.url);
    uniqueRequestId.create(id => {
      let tracer = SAMLTrace.TraceWindow.instance();

      // Maybe revise the HTTP method on redirected requests
      let alterationResult = tracer.reviseRedirectedRequestMethod(request, id);
      id = alterationResult.id;

      let entry = tracer.httpRequests.find(req => req.id === id);
      if (!entry) {
        // Skip further execution if no precedingly issued request can be found. This may occur, if tracing
        // new requests is paused. Requests that were issued before pausing will be found and handled.
        return;
      }

      entry.headers = request.requestHeaders;
      tracer.addRequestItem(entry, () => entry.res);
      tracer.updateStatusBar();
    });
  },

In particular: tracer.addRequestItem(entry, () => entry.res); to tracer.addRequestItem(entry, () => entry.res || {}); or so

So the whole trace can be exported dispite one of them acts oddly.

[thijskh]

Any idea what the exact issue is with that request? Is that visible in the tracer view?

[bzbzh]

Yes it is. No idea at this point.

[kellenmurphy]

@bzbzh were any of the traced events blocked by Firefox due to a security warning, i.e. for a self-signed certificate which hadn't been accepted? Or which had popped the warning and then you accepted to proceed anyway? i.e. see: https://github.com/simplesamlphp/SAML-tracer/issues/66#issuecomment-1201177744

I'm able to replicate the trace js error that causes a null export under that condition.

[bzbzh]

@kellenmurphy I have no "Accept Risk and Continue" message. The certificate is a let's encrypt one. Is there another way/thing to test?

[kellenmurphy]

@bzbzh Okay, no need for more testing... it is telling though that there's something odd about certain traces. I'm going to dig on the thread I have re: self-signed cert warnings to see if I can isolate why that gets the null... and maybe we'll solve your problem as well in the meantime?

[khlr]

I'm able to replicate the trace js error that causes a null export under that condition.

Hm... So @kellenmurphy was able to replicate this... I wasn't. I used the super-handy testing website https://badssl.com. Clicking e.g. the expired link leads to SAML-tracer tracing the request without any response (due to the blocking by the browser).

However, this trace can still be exported without any problems. The response-less request simply does not end up in the output. Ok, that could of course also be considered an error. But that would probably be a separate topic.

What exactly do you have to do to recreate the null error?

[chris18890]

I seem to have come across the same issue

Env/actions:

• Windows 11 pro with AVG
• Google Chrome 121.0.6167.140
• Incognito window
• trying to access https://portal.cloud.hashicorp.com/

I'm able to see the results of the SAML trace onscreen, but when I do an export I get a 4 byte file that just has the word "null" printed in it.

[tvdijen]

Unfortunately that's not reproducible for us @chris18890 ...

[thijskh]

It would be great if someone who encounters this issue and can actually reproduce it, could see if they can debug it/find the cause.

[chris18890]

Oddly enough though, it worked perfectly on firefox!

Unfortunately that's not reproducible for us @chris18890 ...

Is there anything I can help with in terms of reproducing it?

[tvdijen]

@chris18890 If you can reproduce it, you could try and opening the 'developer tools' in your add-on window and see if anything is being blocked why you try to export.

[BryanSD]

I believe I ran into this issue as well, and may have steps to reproduce in Firefox. You can contrive a scenario where this works in the context of a SAML exchange, but it's equally present on a visit to google.com:

1. Open up the Web Developer Tools in Firefox and enable Request Blocking (icon looks like 🚫).
2. Add google.com as a resource to block.
3. Open SAML Tracer
4. Back in Firefox, navigate to google.com
5. Notice in the Network tab any requests to google.com show "Blocked by DevTools"
6. Notice the corresponding requests in SAML Tracer are grayed out.
7. Attempt to Export from SAML Tracer. Note that 0 requests can be exported. (if any other entries are present and an export can be accomplished, then re-import it and notice the google.com requests are missing)

This reproduction works because, from my understanding, a bug in Request Blocking in Firefox allows the request to actually be sent but the response is ignored: https://bugzilla.mozilla.org/show_bug.cgi?id=1756770

The real-life use-case where I saw this occurred when JS in the page was cancelling the request before it could ever complete - the request went out, but it was cancelled before the response was received. However, no record of the request could be found in a SAML Tracer export even though it appeared "live" when viewing the network activity there.