FusionAuth/fusionauth-react-sdk

No error message when the wrong client id is provided

Closed this issue · 4 comments

No error message when the wrong client id is provided

Description

There is no error message to the developer if they configure this SDK with the wrong client id, just a blank screen.

Affects versions

0.25.0
using fusionauth 1.45.1 hosted backend.

Steps to reproduce

Steps to reproduce the behavior:

  1. Configure a new react app with this library.
  2. Create an Application in FusionAuth
  3. Put the wrong client id in the react app createRoot call.
  4. Add a login button to the app
  5. Try to login using an incognito browser.

Expected behavior

I don't know, but at least a message in the JS console.

Community guidelines

All issues filed in this repository must abide by the FusionAuth community guidelines.

Additional context

You can grab this sample app if you want a super simple testbed: https://github.com/FusionAuth/fusionauth-example-react-guide

The SDK passes along the clientID prop when it redirects to the FusionAuth login page which shows the below json. Seems like proper developer feedback when the SDK is configured with the wrong clientID.

{
  "error" : "invalid_client",
  "error_description" : "client_id: foo-bar is not valid.",
  "error_reason" : "invalid_client_id"
}

In order to show this error message from the react app, the SDK would need to send a special network request to some endpoint that validates the clientID. Unless we want to do something like that, this issue may be closed without code changes.

Hmmm. Did you run through the replication steps? Maybe the behavior has changed, but when I added the wrong client id in the createRoot call, I didn't get any feedback.

Hmmm. Did you run through the replication steps? Maybe the behavior has changed, but when I added the wrong client id in the createRoot call, I didn't get any feedback.

I did. The feedback comes on redirect to the FusionAuth hosted page, not the react app, since the react SDK doesn't validate the clientID (unless we were to add a special network request to some endpoint that does so). One of my colleagues will look at this as well.

Okay, maybe I missed something. Feel free to close, I think the message after the redirect is totally fine.