Disable the application configuration for this webhook. That is not doing what you think - it is a legacy configuration that causes some confusion.

https://fusionauth.io/docs/v1/tech/events-webhooks/#form-fields-5

have you seen this https://github.com/jerryhopper/fusionauth-app-multiarch ?
it's from community member @hopper-jerry and may meet your needs.

@jlinton,

As a related note, you can elect to remove the JWT when calling the login API specifically.

https://fusionauth.io/docs/v1/tech/tutorials/json-web-tokens/#skipping-jwt-creation

Thanks,
Josh

Please check that you configured an SMTP server in the default Tenant (and for every other tenant, for that matter).

It defaults to localhost and port 25, and if you don't have an SMTP server running there, any functionality sending emails, like forgot password, won't work.

To work around this, you can set the password for any user using an API key and the User API: https://fusionauth.io/docs/v1/tech/apis/users/#update-a-user

Yes. That’s how it currently works.

We have on the roadmap a more flexible identity system but don't have a current timeline for implementation. Here's the tracking issue: https://github.com/FusionAuth/fusionauth-issues/issues/1

you can add to the database_url: ?ssl=true&sslmode=require (pick the mode you actually require)

if your server supports tls1.3+ you should force 1.2 on the client:
FUSIONAUTH_APP_ADDITIONAL_JAVA_ARGS="-Djdk.tls.client.protocols=TLSv1.2"
(https://fusionauth.io/community/forum/topic/938/secure-db-connection-with-tls-1-3/4?_=1629097757303)

Hi there,

I was just double-checking this, and the algorithm dropdown doesn't need to be manually set since it automatically changes to the value of the algorithm in the header.

But while testing this I actually got it to verify; not sure what was different each time since I could have sworn I tried both the public key and the certificate with and without the PEM headers (looks like the PEM headers are definitely necessary), but maybe I was using the wrong key or something.

Anyway thanks for looking into this!

@jlinton

This feature will be released as a webhook very shortly as part of 1.30 so keep your eyes peeled when we announce this!

Related webhooks coming in this release

user.password.reset.send user.password.reset.start user.password.reset.success user.password.update

Thanks
Josh

@jitendrasahu17996

I might need some more context, but what you are asking for sounds feasible.

I would start by looking at SSO to achieve multiple-application login.

https://fusionauth.io/docs/v1/tech/guides/single-sign-on/ https://fusionauth.io/blog/2021/02/09/single-sign-on-sso-with-fusionauth/

Thanks,
Josh

Can you provide a detailed list of the steps you've taken to see this error? This will help us try to perform a recreate.

Please also include the application you are attempting to use to enable this 2FA method.

As of version 1.29.0, we've added a lot more SAML debugging. I'd be interested to know if anyone else runs into this issue and if the extra debugging helps resolve the issue more quickly.

Cheers!
Dan

@dtokarz1

Great! There is also some of this functionality built into FusionAuth that you could explore as well under Tenants > Registration > Email verification settings

Screen Shot 2021-08-03 at 1.42.38 PM.png

Thanks,
Josh

@renu-rauthan90

Thanks for the report! If this is a bug, I would encourage you to fill out a bug report below with additional details.

https://github.com/FusionAuth/fusionauth-issues/issues/new/choose

Thanks
Josh

Hi @casper!

Welcome to the community. This is working as designed. The import API is currently designed to only write new records to the database and not check if the record is already duplicated. This is partly for performance reasons. It maybe be possible to write a script to check existing records, and then only import "new" users based on that feedback, but we do not have any current documented cases of this.

There is an option to get additional information about what is failing on your import.
https://fusionauth.io/docs/v1/tech/apis/users/#import-users

validateDbConstraints [Boolean] OPTIONAL Defaults to false Set this value to true in order to perform additional validation of the request. The import request is intended to be used to populate the initial set of users, this means FusionAuth does not expect to find duplicate users in the database. If a duplicate is encountered a 500 will be returned without this additional validation. If you intend to use this API with existing users in FusionAuth set this value to true to request additional validation be performed on the input request and a 400 response will be returned with JSON body indicating the duplicate values encountered. Setting this value to true will dramatically decrease the performance of this request. If importing large numbers of users in a single request you may need to increase request timeouts to ensure this request does not timeout before it has completed.

I hope this helps,
Josh

With self-hosted FusionAuth, you are downloading the software, starting up a server (VM in the cloud, in your data center, wherever) and running it yourself. You are responsible for monitoring, backups and everything else to keep your FusionAuth instance available to your customers.

With all the cloud options, we run FusionAuth for you. Each level of cloud has a different set of constraints, as outlined in the pricing links (click on the ? for more details), but in general we take care of operating FusionAuth for you. You still control the upgrade cycle, but much of the other maintenance is handled by us.

@spacho

I don't see an open issue. Feel free to log one below!

https://github.com/FusionAuth/fusionauth-issues/issues/new/choose

Thanks,
Josh

@hamburg-developer

Can you elaborate a bit more about what you are looking for functionality-wise? More context may help to address your question.

Thanks,
Josh