Hi James,

Glad to help! Let us know if you have any more questions.

Hi Dan

Thanks a lot. It's fixed. The reason is the wrong configuration in facebook account.

Regards
Co

It's configurable. If you go to the tenant details page, then to the Advanced tab, you'll see the setting there; it's called Authorization Code. It's also documented in the tenant API, search for tenant.externalIdentifierConfiguration.authorizationGrantIdTimeToLiveInSeconds here: https://fusionauth.io/docs/v1/tech/apis/tenants

Looks like valid durations are between 1 and 600 seconds.

To get User Ids, you’d want to use the Search API, and make requests in smaller windows to keep under 10k and than add the results. For example, you could request all users with a username starting with a, and then b, and so on. Definitely recommend scripting this.

As long as you have enough RAM for ElasticSearch, 10k for numberOfResults should be just fine. You’ll just need to make sure your query is narrow enough such that the totalNumberOfResults that comes back from FusionAuth is below 10k, otherwise you won’t know for sure if you received an exhaustive result set from your query.

We will be enhancing the Search API shortly to work around this Elasticsearch limitation (github issue).

There is a Totals report that is available in the UI or API.

https://fusionauth.io/docs/v1/tech/apis/reports#generate-totals-report

hiya, have you tried redirect_uri? That should work, but it will require you to configure the allowed redirect_uris in your FusionAuth application's OAuth config (on the OAuth tab in the admin ui). wildcards aren't recommended for the redirect_uri due to security concerns (see https://tools.ietf.org/id/draft-ietf-oauth-security-topics-05.html#rec_redirect ).

The other alternative is to pass a state parameter, which should be returned unchanged to you by FusionAuth. You could then have your code look at that parameter and redirect as needed.

You could also look at caching the value in localStorage and retrieving it after login has occurred.

Hmmm. Since you haven't made any changes and aren't seeing any other errors, can you try to reindex?

Navigate to system and then re-index in the administrative user interface?

That should solve the issue.

It looks like the ElasticSearch index is locked by a prior process. I'd attempt to see who has a lock on that file, or you could try to restart the elasticsearch service. net stop FusionAuthSearch and net start FusionAuthSearch should do it.

From some googling, this may be a virus scanner, or perhaps some other Windows process may be causing this type of error with Elasticsearch.

Our validation takes in inverse approach. The setting is actually to require a non-alphanumeric character. So any character that is not alphabetic, or a digit, will satisfy this requirement.

There is not a fixed set of symbols as this would reduce the password entropy, which is generally a bad idea.

When the user arrives at the Forgot Password we capture all of the OAuth2 state, including PKCE parameters. When the user completes this flow, we replay all of this state, so the login will complete using PKCE.

If you want the Forgot Password flow to complete without this step, you can either handle Forgot Password in your SPA, or when you redirect them to the FusionAuth Forgot Password page /password/forgot - do not provide client_id on the request. If client_id is not provided, we will assume this is not within the OAuth2 workflow and we will not attempt to log the user in at the end of the flow. In this case, the user will end up on /password/complete.

Glad you figured it out!

I just filed a PR to tweak the docs to make it more clear: https://github.com/FusionAuth/fusionauth-site/pull/194

If you’re looking to update the password, you can use the Update User API, or the Change Password API.

Neither of these APIs accept a hashed password and salt however, it accepts a plain text password that it will in turn salt, hash and then persist.

Check out both these APIs here: https://fusionauth.io/docs/v1/tech/apis/users

This is not currently handled by FusionAuth. You would have to use another application firewall of some sort that offers rate limiting. Here's an example for nginx: https://docs.nginx.com/nginx/admin-guide/security-controls/controlling-access-proxied-http/

We have discussed adding this feature, but due to the other options available it has not yet been prioritized. Feel free to open a feature request on GitHub.

Hiya,

It looks like this use case is documented in the 'Complete the Google Login' section of the API documentation: https://fusionauth.io/docs/v1/tech/apis/identity-providers/google#complete-the-google-login

High level:

Developer does the Google login dance themselves Google returns a token Developer calls the IdP Login API as outlined in the above link.

Hope that helps. I've also filed a PR against the documentation to highlight this functionality.

Related bug report: https://github.com/FusionAuth/fusionauth-issues/issues/842

Hmm. That's weird.

I don't see anything wrong with your config, especially if your colleague uses it. I'd suggest:

trying a different smtp host/solution (sendgrid has a free option) opening up a ticket with mailgun

I tend to use a local solution like mailcatcher, since email deliverability is a bit of a dark art.

Hiya,

If the user has the same email registered across multiple accounts (Facebook, Twitter, Google) they should be able to login with each of those and they'll be all tied to the same account in FusionAuth. If they are different email addresses, we currently have no way to reconcile them.

But I think the user has to go through and sign in with each provider for FusionAuth to get the metadata into its system.

These github issues might be of interest:

https://github.com/fusionauth/fusionauth-issues/issues/1

https://github.com/fusionauth/fusionauth-issues/issues/751