After login then isAuthenticated = true, but Viewer = null

[tuanfront-end]

Description

I'm not sure if this is an error from Faustjs or from my WordPress, however I couldn't find any problem from WordPress so I'm posting it here because it could be an error from Faust.

When starting a new Faustjs project, doing login and then isAuthenticated = true, but Viewer still always returns null.

The strange thing is that this problem doesn't happen on local WordPress but it does happen on my public WordPress: https://admin.librum.rs/wp-admin/

Steps to reproduce

1. Clone the Faustwp-getting-started
2. Set environment variables to my WordPress,

NEXT_PUBLIC_WORDPRESS_URL=https://admin.librum.rs
FAUST_SECRET_KEY=3c8a579b-4d48-4d96-9df6-840b6674d5db

3. Add the following code to the pages/example.js file

const { login, data, error } = useLogin();
const { isAuthenticated, isReady, viewer } = useAuth()

useEffect(() => {
        // This is the account that can log in correctly
	login('test', 'test', '/');
}, [])

console.log('viewer', { viewer , isAuthenticated});

4. After logging in and isAuthenticated=true, the viewer is still always null
5. Expectation: viewer must return logged in user data.

Additional context

No response

@faustwp/core Version

^3.0.1

@faustwp/cli Version

^3.0.2

FaustWP Plugin Version

1.3.1

WordPress Version

6.5.4

Additional environment details

WPGraphQL: Version 1.27.0 |

Please confirm that you have searched existing issues in the repo.

• Yes

[IDabetic]

Hi, are we going to get an answer to this?

[theodesp]

Hello @tuanfront-end. Not sure why. I wasn't able to reproduce this issue in a site using Local. The viewer data does get populated.

Are you able to query the viewer data using that user test in WP GraphQL admin as well?

[tuanfront-end]

Hi @theodesp
Yes, with Local the feature works well, but with the WordPress I shared it doesn't work. I tested the getViewer query in the WP GraphiQL IDE and the results still returned fine, but when running the viewer in the Faust project it was always null.

I hope you give my WordPress a try and hopefully, you can give me some insight

NEXT_PUBLIC_WORDPRESS_URL=https://admin.librum.rs
FAUST_SECRET_KEY=3c8a579b-4d48-4d96-9df6-840b6674d5db

Thank you so much in-advance

[jan-clockworkwp]

I am experiencing the same issue where the problem can go unnoticed, but since you have set experimentalToolbar: true, you will start getting the error TypeError: Cannot read properties of null (reading 'shouldShowFaustToolbar') in ToolbarAwaitUser@Toolbar/Toolbar.js. This is because the viewer is not updated properly after successful authentication.

I can confirm that WPGraphQL is returning the proper viewer value for authenticated requests when executed in the WordPress Admin GraphQL IDE. The strangest part is that I have identical code on two separate machines with the same content, but I'm only experiencing this issue on the machine where I recently set up my site.

I've tried downgrading the Node version to match the older setup, and updating al faust wp and js packages to the latest versions, but the issue persists on the newly set up application with the same data and packages as the other one. Adding the skip parameter to the viewer query, as suggested in this GitHub issue (#1443), does not help in this case, as the user is properly authenticated.

Similar issues:

• useLogin and useAuth do not work together to update isAuthenticated/viewer #1923

Environment information:

• WordPress/Bedrock v6.6.1 with an SSL certificate, Faust running on localhost:3000 without an SSL certificate
• Running Faust with CORS disabled and NODE_TLS_REJECT_UNAUTHORIZED=0
• Node v20.17.0
• Latest Faust WordPress and JavaScript packages, except for the WordPress Faust plugin, which is on v1.3.2, as v1.4 is not available for Composer installation.

Thank you for looking into this. The current temporary solution is to set experimentalToolbar: false, which is far from ideal.

[jan-clockworkwp]

Just wanted to let anyone know that the issue I described in my previous comment has been resolved in a rather strange way. I have simply restarted the process, which I've done many times yesterday, and the only difference this time was that I started the application without CORS disabled. Everything seems to be working as expected now, and the Viewer object contains the proper information. The issue also appears to be resolved when the application is started with CORS disabled. Additionally, I have flushed the permalinks on the new installation, so it looks to me that this action is more likely to solve that rather than the application restart, but I cannot say for certain that this fixed the issue, as I did not test it immediately after.

If anyone else encounters a similar strange issue related to the viewer object, you may want to try flushing the permalinks on your new installation. Hope this helps anyone facing strange issue with the viewer value not being set on FE after successful authentication.