Open bzbzh opened 2 years ago
Any idea what the exact issue is with that request? Is that visible in the tracer view?
Yes it is. No idea at this point.
@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.
@kellenmurphy I have no "Accept Risk and Continue" message. The certificate is a let's encrypt one. Is there another way/thing to test?
@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?
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?
I seem to have come across the same issue
Env/actions:
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.
Unfortunately that's not reproducible for us @chris18890 ...
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.
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?
@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.
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:
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.
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:
When trying to stringify "req.getResponse()" when it returns null.
I wonder if it would be a good solution to alter this:
In particular:
tracer.addRequestItem(entry, () => entry.res);
totracer.addRequestItem(entry, () => entry.res || {});
or soSo the whole trace can be exported dispite one of them acts oddly.