@dan I opened the request. Thanks!

@dan Hello, reaching out to know if this still the same, ie no way to know whether an user has a password or not?

@hendrik-ebbers I am a little confused on the ask. It sounds like you want a user to be able to log into a webpage and then be able to call your apis? Would they call the apis from an interface you provide in the web application or from some other application?

@alex-patterson Thank you for sharing this. I did not even notice this in the documentation. I will give it a try.

@dan said in Retrieving Data using FusionAuth API:

Great! We have a PR out to revisit the search documentation which I just merged. So hopefully that will be clearer for folks in the future.

Back to this comment of yours, I meant that the first line in this screenshot kinda confused me, since I thought that you're searchQuery will be searched only for these fields and not all of the existing fields if you call this this endpoint http://{{dockerhost}}:{{fusionport}}/api/user/search?queryString=*

And also I did not know that I can do something like http://{{dockerhost}}:{{fusionport}}/api/user/search?queryString=tenantId:uuid

@jarrod We just rolled out such an app to one of our clients, and I'm happy to share my experiences with you.

Do we whitelist a large amount of callback URLs?

We haven't. Same as in your case, the user registers through a self-serve sign-up form where they enter the tenant details, such as the subdomain. During tenant creation on our backend, we simply construct the new tenant URLs for login and Oauth (we configure Oauth because we have a desktop app connecting to this same backend).

const newFusionAuthAppConfig = { name: `"${organizationName}"'s Project`, oauthConfiguration: { ...blueprintAppConfig.oauthConfiguration, enabledGrants: [GrantType.authorization_code, GrantType.refresh_token], authorizedRedirectURLs: [`${newAppUrl}/api/oauth-redirect`], logoutURL: `${newAppUrl}/api/logout`, }, loginConfiguration: blueprintAppConfig.loginConfiguration, };

So when the new tenant is set up, it already has everything tenant-specific. We use the default tenant as the blueprint for some of our configurations - blueprintAppConfig.

Do we create an Application per custom domain? (Does this mean we have to sync users?)

This is what we did, but I guess it depends on your use case. For us, it was important that one user can register on different subdomains with the same email.

Do we redirect to the main app and perform some kind of sidechannel/backchannel SSO iframe magic?

I can assure you there's no magic once you correctly set up the tenant creation. The entire front end (React here) works the same as before. Most of the "magic" on the backend is simply realizing from which tenant the request came and constructing a tenant-specific Fusion Auth client to retrieve tenant-specific user details, apps, etc.

FusionAuth's official documentation on multitenant setup was an immense help to us.

@egli If you're using TypeScript/JavaScript you can implement a simple page with inputs and call

const newUserFields = { firstName: form.firstName, lastName: form.lastName, }; await fusionAuthClient.patchUser(user.id, { user: newUserFields, });

or use the Update user REST API to pass firstName and other fields.

@jswgger007 Is it possible that you have a .env.local that would overwrite the default values in .env?

Is this issue happening when you run the app locally or in some other environment?

@kasir-barati Makes sense. Thanks for the feedback!

@whuysentruit

Sure, we welcome feature requests from the community! Members can upvote them and we review the upvotes when considering future development.

Here's the GitHub repo to file the issue in: https://github.com/FusionAuth/fusionauth-issues/issues/

Please feel free to reference this forum post and give as many details as you can. This helps us understand the use case.

More about our roadmap process: https://fusionauth.io/docs/operate/roadmap/roadmap

@jan-1 , unfortunately I don't have a great suggestion for you. It looks like @robotdan is taking a look at the issue you created. I will follow the issue and check back in, once they update it.

@lambio hmmm. That code value changing seems to indicate that the authorization code grant isn't completing. This might cause the behavior you are seeing (because the tokens never get stored in the browser).

Are you running both systems on localhost? Are you using docker?

Sharing a bit more about what the system looks like would be helpful.

Another thing you can do is enable debugging in your fusionauth application configuration (go to the admin panel, edit your application, enable debugging) and then viewing the event log (go to system -> event log) as you try a login. That might be helpful info to share as well.

Thanks @daniel-lohse.

This additional info would be helpful:

Type and version of your database Any negative issues you see, unless this is only a worrisome event log entry Any behavior you see that triggers these (if you have replication steps)

And I can file an issue.

@mark Awesome!

@joseantonio you'd have to re-authenticate with the hosted login pages. Custom login pages don't set the FusionAuth single sign-on cookie.

There is an open github issues about this: https://github.com/FusionAuth/fusionauth-issues/issues/1515

@mo-mustkem It is a Theme Template Variable. Please check out https://fusionauth.io/docs/customize/look-and-feel/template-variables#oauth-authorize. rememberDevice is in /oauth2/authorize

@slifty Let's start with what your desired workflow is and go from there. How would you like the login to work?

@twilkinson That message is logged when an HTTP client closes a connection before FusionAuth can fully send a response. This could be as innocuous as a user closing their browser before a page has completed loading.

Some thoughts:

Do you see other exceptions in the log? Possibly related to database connections? What does the load look like on the DB? Do you see any issues on Elastic if you are using it?

@lambert-torres there is no queue that is kept, you would either need to look at the logs to specifically find the users during that time. Or follow the below steps.

You can resend the verification emails for newly registered users. FusionAuth provides an API endpoint for resending a user registration verification email.

https://fusionauth.io/docs/v1/tech/apis/users#resend-verification-email

Here are the steps to follow if you want to manually verify:

Use the PUT /api/user/verify-email?email={email} endpoint to request a new verification email. This will return a verificationId in the response. curl --location --request PUT 'http://localhost:9011/api/user/verify-email?email=<my_email@my_email.com>' \ --header 'Authorization: <API KEY>' \ --header 'X-FusionAuth-TenantId: <TENANT_ID>' The response should look like this: { "verificationId": "SOME_REALLY_LONG_ALPHANUMERIC_STRING" } Use the POST /api/user/verify-email?verificationId={verificationId} endpoint to mark the user as email verified via API.

Please note that you need to ensure that you don't have skipVerification set to true when a user registers for an application via API and your application has verifyRegistration set to true. This can be set programmatically via the API or via the admin UI.

For more details, you can refer to the FusionAuth documentation and the FusionAuth community forum.

Please ensure that your connection to SendGrid is restored before attempting to resend the emails.