spurious text '[object Object]' on home page

[NikolayMetchev]

spurious text '[object Object]' on home page

Description

please see screen shot for example of some spurious text at the top of the home page.

Affects versions

1.23.3
1.25.0

Steps to reproduce

Login and observer

Expected behavior

the spurious text not to be there

Screenshots

Platform

(Please complete the following information)

• Device: Desktop
• OS: macOS
• Browser + version chrome

Additional context

This is on a Fusion Auth hosted version here:
https://login.posttrade.dev.ptnonprod.com/

[mooreds]

Hiya, can you please create a test account for me on the server you link to? Please feel free to email me details at dan at fusionauth dot io.

Also, what is the output if you run this javascript in your console?

window.navigator.userLanguage || window.navigator.language

[NikolayMetchev]

[robotdan]

Thanks for reporting @NikolayMetchev - we've seen reports of this a few times in the past and have been un-able to track it down and recreate! Hopefully we'll nail it with your report!

[mooreds]

Hmmm. Interesting. So a couple of things.

I can't resolve login.posttrade.dev.ptnonprod.com, I assume because that is an internal domain name not broadcast to the internet. I can login to paxos-dev.fusionauth.io with the credentials you provided. Unfortunately, I don't see the issue (I thought it might be locale related, but setting my locale to en-GB didn't help).

I have a few further troubleshooting steps that I'd love your help with.

Can you log in to paxos-dev.fusionauth.io (rather than using the login.posttrade.dev.ptnonprod.com) and see if you still see the [object Object] message displayed?

Can you tell me if you are behind a proxy? https://www.whatismyip.com/proxy-check/ will display that info, for example.

Can you visit https://paxos-dev.fusionauth.io/admin/proxy-config-test and https://login.posttrade.dev.ptnonprod.com/admin/proxy-config-test and share the results?

Thanks!

[NikolayMetchev]

Hi,
logging into https://paxos-dev.fusionauth.io/admin/ does have the problem still there:

I am not behind a proxy. I am VPN'd into our corporate network though.

the two proxy-config-test urls result in a blank page.

[NikolayMetchev]

If I log in with Safari the problem doesn't reproduce.

[NikolayMetchev]

So I just emptied the chrome cash and hard reloaded and the problem has gone away.

[NikolayMetchev]

I probably shouldn't have done that because I can't reproduce it anymore.

[mooreds]

Well, at least we have a workaround :) .

I hopped on a VPN and was unable to replicate. Let's leave this bug open and see if it pops up again.

Please feel free to delete or disable my account on the dev server.

[NikolayMetchev]

Actually it is back! Happy to do a screen share to help with debugging.

[NikolayMetchev]

It might be related to SAML as that is what I am using to log in.

[mooreds]

Hiya @NikolayMetchev ,

Hmmm. I appreciate the offer of a screenshare! Before we do that, though, can you record a HAR file and send that over to me, please? https://toolbox.googleapps.com/apps/har_analyzer/ has steps.

I would like to take a look at what you are seeing and determine if there's some way to replicate it locally, or some other clues, before doing a screenshare.

[NikolayMetchev]

I have emailed you the har file.

[mooreds]

@NikolayMetchev thanks, received!

I looked at it and the only thing that jumps out is the cookies saving off state for the audit and event logs. Do you see the issue when you clear cache and login immediately, or is it after browsing around a bit in the admin UI?

Also, are there any logs in the System -> Logs section (which are server side logs) that line up with the issue you are seeing? I looked at those logfiles but didn't know what time you were seeing the error.

I consulted with a team member and we had some ideas of additional troubleshooting steps we could take internally. I'll see if they make sense and get back to you.

I do think I can say with some certainty that this is a UI bug and not going to affect functionality at all.

[NikolayMetchev]

I logged in and out a few times from a few different instances of Fusion Auth.

[robotdan]

As an aside, functionally what we are doing when we load that page is opening an iframe which loads a hidden page that makes a POST request to ourselves. We then inspect this POST request for the correct proxy headers to see if everything is configured correctly and if the user should expect any issues with the configuration at runtime.

To do this, we are using the Window postMessage() API ( https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage ). We then listen for the message event on document and consume the message and assume it is HTML and insert it into the DOM. There must be some edge case where the message we receive is either not what we sent, or we send a non-HTML value and instead is some object.

Example screenshot of what I would expect to be shown when a proxy configuration is not correct:
#265 (comment)

If this is re-creatable on a system we have access to, we could add some debug info to the JavaScript and see what is being sent to the message event listener.

[NikolayMetchev]

I noticed just now that the problem had gone away. So I logged out and logged back in straight away and that has reproduced it. So I think it has something to do with logging out and back in again. You might want to try that Dan with the account I created for you.

[mooreds]

Thanks @NikolayMetchev , I have tried that, but will try again.

[mooreds]

FYI @NikolayMetchev I have modified the javascript with additional logging which will show up in your javascript console.

[mooreds]

So it looks like the code that is populating the proxy information is called two times with different messages. It's not clear to me exactly why, but they are different enough that we can distinguish between them.

[robotdan]

@NikolayMetchev do you have any chrome extensions installed, if so, which ones?

It looks like it is common for Chrome extensions to use the postMessage API for various reasons. Dan has a fix in any case, but this may help us recreate.
https://owasp.org/www-pdf-archive/OWASPLondon_PostMessage_Security_in_Chrome_Extensions.pdf

[NikolayMetchev]

Hello,
I have the following extensions:

[Oceanswave]

It does seem to be extension related - I get the [object Object] consistently when running the wappalyzer addin which injects a tag onto the page. Disabling the addin makes the object Object go away.

[robotdan]

Great, thanks for the confirmation @Oceanswave .

We have a fix coming out shortly under https://github.com/FusionAuth/fusionauth-app/pull/38 that will resolve it. The bug is that we made an assumption that nobody else was going to be using the window.postMessage API on the page but us. ;-(

Bad assumption, fix forthcoming.