Internal Note: tracking via https://github.com/FusionAuth/fusionauth-issues/issues/1231

Hi @joshua , thanks for your response.

Is the code that you are sending related to MFA? Or some other business logic? If MFA related, there may be more options that we can explore.

My use-case is related to our business logic, our app is only available in certain countries; thus we require users to validate they're in one of those countries via a code sent to their phones. I've read the docs about the Form API but I don't quite see how would it solve this issue (and, as you said, would negate the benefits of advanced forms). The other option would be just to validate the phone outside FusionAuth (like we're doing right now), but I would like to migrate all the registration-related steps into FusionAuth.

Yes. As of 1.27, you can use a verification strategy of FormField. This is configured on the tenant: https://fusionauth.io/docs/v1/tech/apis/tenants/

You then provide the one time code in the oneTimeCode request body parameter. More about this in the email verification docs: https://fusionauth.io/docs/v1/tech/apis/users/#verify-a-users-email

Note that this feature only works with email gating at the current time, which is a reactor feature requiring a paid license.

@naughtly-keller! You are right! Good spot!

@alessiocata I would recommend you peruse the entire guide that @naughtly-keller links to. It goes through many different situations in which Passwordless can be applied and used within FusionAuth. Pick the one that is best suited for your business needs.

Thanks,
Josh

Setting the "Allowed origins" in the Application settings did the trick.

To clarify my current MFA delivery setup (v1.25), I have it configured with "delivery": "None" and this enables the Authenticator and backup codes via the Twilio integration.

Will this keep working? Or do I have to update each user and enable the "sms" method? Is it even possible to enable the "sms" method without having a code that was sent to the mobilePhone of the user?

Unfortunately in this case, I believe this is the current expected behavior for the MFA workflow.

If you have a specific use case that necessitates changes to this, please feel free to log a feature request with all the details and any other considerations 🙂 👍

https://github.com/FusionAuth/fusionauth-issues/issues/1234

I end up using a docker image of mailcatcher.

I use the default docker-compose.yml, but use this docker-compose.override.yml:

version: '3' services: mailcatcher: image: yappabe/mailcatcher ports: - "1025:1025" - "1080:1080" networks: - mailcatcher search: image: docker.elastic.co/elasticsearch/elasticsearch:7.8.1 environment: cluster.name: fusionauth bootstrap.memory_lock: "true" discovery.type: single-node FUSIONAUTH_SEARCH_MEMORY: ${FUSIONAUTH_SEARCH_MEMORY} ES_JAVA_OPTS: ${ES_JAVA_OPTS} # Un-comment to access the search service directly # ports: # - 9200:9200 # - 9300:9300 networks: - search restart: unless-stopped ulimits: memlock: soft: -1 hard: -1 volumes: - es_data:/usr/share/elasticsearch/data fusionauth: depends_on: - search - mailcatcher environment: SEARCH_SERVERS: http://search:9200 SEARCH_TYPE: elasticsearch networks: - mailcatcher - search networks: search: driver: bridge mailcatcher: driver: bridge volumes: es_data:

Then I configure the SMTP settings to use the hostname mailcatcher and the port 1025. I can then send email and view it in the mailcatcher interface, at localhost:1080.

Here's the relevant dockerfile: https://github.com/yappabe/docker-mailcatcher/blob/master/Dockerfile

Here's more about mailcatcher: https://mailcatcher.me/

The user and registration may have a username field. The username field on the user is the one that can be used to login. In general you will want to use the Search API for those types of queries rather than directly accessing the database.

The reason is because the API is documented and stable, and the database is undocumented and may change.

Hi @luke-fishman,

I have a few questions for you to see if we can get to the bottom of this.

Is this an ongoing problem or has it recently surfaced? If recently surfaced, has anything changed which would slow your queries down? For instance, have you made any architecture changes? Was this user query much faster in the recent past?

What do queries from the Admin UI look like (are they performant?)?

Other things to evaluate include the size of your database and your architecture to make sure it's right-sized for your use case.

Finally, are you seeing anything in the error and event logs in FusionAuth (or in your server) that would indicate a larger problem?

Thanks,
Josh

You will need to obtain the default tenantId from the UI.

If you are using kickstart, you have the option to set the default tenantId so that it is predictable.

Thanks for filing a github issue as well!

https://github.com/FusionAuth/fusionauth-issues/issues/1227

Hi @tl-fa,

You can view our Roadmap Guidance regarding how features are implemented into FusionAuth. A good snapshot of current development can be found here as well.

We will certainly update any related issue cards as development moves forward!

Thanks!
Josh

@maarten,

Glad that you got this working! If you have any other tips about how you got it working, that might help other users in a similar situation.

Glad it worked out!

Thanks,
Josh

A duplicate of https://fusionauth.io/community/forum/topic/438/password-complexity-rules

But the easiest way to see this is in the tenant API, since that is where they are configured.

At time of writing, here are the options.

Screen Shot 2021-05-12 at 1.50.12 PM.png

Awesome, glad to help.

Just to be transparent, application theming requires a paid edition license. You can buy one here: https://fusionauth.io/pricing/editions/

Here was some feedback from other users:

I have a k8s cron job that queries the FA eventLog API and sends them as DataDog events, then depending on severity a DataDog Event monitor will fire. Other than that, I feel rather blind.

we havent been able to upgrade quite yet, but 1.26 added a prometheus endpoint
right now we use the datadog jmx integration to get some stats, and we also do things like http monitoring

Here's the prometheus endpoint docs: https://fusionauth.io/docs/v1/tech/tutorials/prometheus/

It looks as though Trend Micro (or whatever security solution is being used as a pass through) is modifying the URL and not properly preserving the URL encoding. You will need to inquire with Trend Micro about why this would be occurring.

Interesting, not sure how this would happen. Thanks for the report @stuart-auld - I agree, this is not a good dev experience. We will identify this cause and try to failure better.

Tracking via GitHub Issue #1217