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

You could use the skipVerification parameter (set it to true) on the user or registration create statement, and then the https://fusionauth.io/docs/v1/tech/apis/users#resend-verification-email call with sendVerifyEmail set to false.

This would give you a verificationId you could use with this API call: https://fusionauth.io/docs/v1/tech/apis/users#verify-a-users-email

@fusionauth_user, are you using Klemen's schema or did you create your own?

Hiya,

A few questions for you?

What version of FusionAuth are you running?

What step throws the error?

Did you walk through the 5 minute setup guide? That will ensure you have everything configured correctly on the FusionAuth side.

Related GitHub issue with details.
https://github.com/FusionAuth/fusionauth-issues/issues/178

This configuration should be available to you already using the IdP configuration.
https://fusionauth.io/docs/v1/tech/identity-providers/facebook#create-a-facebook-identity-provider

When using the fields and permissions values, can you get the user's first and last name?

You can use the user.data and registration.data fields to store arbitrary key value data.

If the metadata is associated with the user, use user.data. If it is associated with the user's account for a given application, use registration.data.

Note that this field is read/write via the API, but only readable via the administrative UI.

Here are some notes about the limits of these fields: https://fusionauth.io/community/forum/topic/89/how-large-can-the-data-field-be-for-any-of-the-fusionauth-resources

And for the latter option, should I use a webhook for registration events

If you want a separate database, that's the way to do it. Listen for a webhook and create the records then.

Whether you should use the data fields or a separate database depends on what you are trying to do. The data fields are simpler and more tightly tied to the user records. You can also query them, but you'll be writing elasticsearch queries.

If you'd rather write straight SQL or will be storing lots and lots of data about a user (for example, their entire login history for analytics), then a separate database might work better. Of course, that's another system to maintain, so more complexity is the tradeoff.

Looks like another set of bugs:

https://github.com/FusionAuth/fusionauth-issues/issues/839
https://github.com/FusionAuth/fusionauth-issues/issues/840

Sure looks like a bug to me. I was able to replicate.

Filed an issue here: https://github.com/FusionAuth/fusionauth-issues/issues/838 if you want to track it.

I figured it out…. I just had to put state.client_id in parens so it resolved them together.

[#assign clientId = (state.client_id?string)!"dafb6ef6-a2a8-4d34-9d69-59bfed3e31aa" /]

When you re-index, we delete our named index and rebuild it.

You would probably be better off creating your own index.