Please feel free to vote for the issue @mehr-prs , if it is important to you. Here's the general FusionAuth roadmap guidance: https://fusionauth.io/community/forum/topic/172/the-fusionauth-roadmap

No worries.

Please upvote it if you are interested in this moving toward the front of the work queue.

Not really, at least not through FusionAuth interfaces.

If you have particular queries that aren’t working well, you can open an issue in GitHub or a support ticket: https://github.com/FusionAuth/fusionauth-issues/issues

I do not believe so. I just added a github issue for a similar issue: https://github.com/FusionAuth/fusionauth-issues/issues/874

Please feel free to upvote this if the issue describes your goals.

If not, please explain in more detail what you are trying to accomplish.

Not currently.

You could create a single user called anonymous and auth that user to get a generic token.

There is an open issue for a more elegant solution; feel free to upvote it: https://github.com/FusionAuth/fusionauth-issues/issues/525

No, the users must have a password. In this scenario, where you know the users do not have a password, you can just set a secure random password. A UUID, or other securely generated high entropy value.

You can provide the password value, but this will cause FusionAuth to hash it inline, so it will be costly in terms of time and CPU if you are importing a large number of users.

If you don’t want to take this hit at import time, you can provide these users just random hashed values, as long as you provide the factor, encryptionScheme, salt and password FusionAuth will assume this is a hash, and it will not re-hash it.

It means the user won't be able to login.

You should be able to go the user's tab and then expand the 'advanced' section and select a given application.

See this screenshot:

user search with 'advanced' section expanded

Also, see database.maximum-pool-size here https://fusionauth.io/docs/v1/tech/reference/configuration

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.