It is an ever changing list, but the easiest way to see it is to go to the FusionAuth pricing calculator and select the region to see what countries are currently supported.

If you would like us to support a country not currently on that list, please contact us with more details.

Peering is not an option at the moment. If you have a use case for this, please file a GitHub issue with more details about how you'd like to see the feature implemented.

Another option is to self host and run FusionAuth within your cloud network infrastructure. If you'd like to do that and still have help from the FusionAuth team, consider a plan with a support contract.

We support deploying to Bahrain. Not sure if you are looking for best latency, but that deployment would be the closest geographically.

Welcome to the FusionAuth community @matt-0 !

Hmmm.

search.servers=https://user:pass@es.fusionauth.io

works for me. (But I'm running both ES and FA locally.)

Is https://username:password@awssearchurl.com the real value in your system, or did you swap it out?

Also, what version of java are you running?

Yes, they are equivalent. Building this JSON:

{ "search": { "queryString": "fusionauth.io" } }

and posting it is equivalent to a GET with queryString=fusionauth.io.

We have a license FAQ.

If course, if your questions aren't answered there, please feel free to send us an email.

Looking at https://github.com/FusionAuth/fusionauth-java-client/blob/master/src/main/java/io/fusionauth/client/FusionAuthClient.java#L3256

It appears there is no way to search using the Java client that uses a GET, only a POST. However, you can still provide the queryString in the JSON and it will be equivalent to the GET request.

Building this JSON:

{ "search": { "queryString": "fusionauth.io" } }

Is equivalent to queryString=fusionauth.io.

Hope that helps.

Try clicking on the Advanced section on the User Search page and see you find what you're looking for.

Or search like this tenantId:9d92ca33-bc7b-4d13-acd7-f7dc06038396 where 9d92ca33-bc7b-4d13-acd7-f7dc06038396 is your tenantId.

Please note that this is an example for the elastic search search engine. With the database search engine, you can only search for the fields as documented in the API. As of this post, those are:

firstName lastName fullName email username

There is no easy way to do this. You'd have to migrate your configuration, your users and your DNS (if you are standing up a separate system).

If you have all your configuration as scripts, that should be easy to migrate, otherwise you need to move things over manually.

You could probably script a retrieve and then add of all the configuration, but there is no 'export all configuration' option.

For your users, you could do a database dump to get the hashes and do a bulk import. Or if you have developer edition you could set up a slow migration using connectors. The user migration process is broadly documented here: https://fusionauth.io/docs/v1/tech/guides/migration/

DNS migration is like any other DNS migration.

Hiya @hd_steve !

You can change the user's locale and the date format should change in the FusionAuth administrative user interface. More details here: https://fusionauth.io/community/forum/topic/718/how-do-i-change-the-localisation-timezone-for-the-fusionauth-ui?_=1614788141466

Let me know if that answers your question, please.

Thanks,
Dan

hi @stuart-auld

Can you please share more of your configuration? How is the user action configured?

This may be a documentation issue or a bug, but I'd love to learn more.

Thanks,
Dan

Please see this issue for updates on this functionality. Vote for it if this is important to you.

Reconcile is a way of make sure that a user account exists and has the correct data. The remote system is treated as the system of record, but we want a record in our local system as well.

It is a two phase process:

If the user doesn’t exist in FusionAuth (i.e. the OAuth server), they are created The data from Facebook (or any third party system) is merged with the data in FusionAuth and the user is updated

Step 1 is optional and configurable in FusionAuth. We call it Create Registration in the application configuration. If the user already exists, then step 1 is skipped.

@stuart-auld welcome to the FusionAuth community!

There is no within FusionAuth to modify a webhook body.

This may be a feature of interest to the community; I'd encourage you to file a feature request with more details, but we could possibly run a lambda run every time a webhook runs to transform the webhook output. (There's probably scope for adding lambdas in lots of places; here's another one.)

Until that happens, however, you can send the webhook to a process running on a server or using something like google cloud functions or AWS lambda to transform the webhook output.

Yes, if self service registration is enabled (which is set on an application by application basis) and a user who is already logged in to FusionAuth tries to register for such an application, FusionAuth will automatically register them for the app. It also checks that all required profile information is filled out, which is why adding the required field displays the registration form.

You have a few options to do this. Unfortunately the login page, while very customizable in terms of look and feel via themes, is less customizable in terms of functionality and adding fields. Here are some options:

don't use our hosted login pages, instead build your own login pages (and all the other stuff like reset password, etc) using the Login API. You get total control of the login experience, at the cost of more custom code. check for consent when the application is loaded, after authentication. You could store a consent variable on the user object (in the data field) or use our consent model. Basically, after the user authenticates, take them to an interstitial page unless they have given consent. Put that logic in the application page they first land on. use javascript and customize the theme. Add a consent checkbox to the login form, and set a cookie once the user consented so you don't record the consent multiple times. Make a call via javascript to an API (which you'd have to write) to record when the consent was given.

Another option would be to use advanced registration forms for self registration and create a consent that would be required at sign up. Naturally, this doesn't help if you aren't using self service registration.

Regarding the SPA and proper authentication flow, there are some more things to consider. First, if your SPA is served from the domain that is different from your backend's domain (eg. using Vercel to host SPA frontend) then you'll have issues with cookies between different domains. Another thing is security, specifically CSRF. You'll possibly have to implement some CSRF tokens to handle this. There is a lot of information regarding these topics on the Internet but still it doesn't seem to be very easy to implement. The first link I've found on the topic: https://ideneal.medium.com/securing-authentication-in-a-spa-using-jwt-token-the-coolest-way-ab883bc372b6.
Would be great if FusionAuth docs can also describe these issues (different domains, CSRF).

Because of that it is worth considering if some other flow isn't better - AuthorizationCode + PKCE that doesn't touch the backend at all (no cookies, no CSRF issues, but you have to be careful with XSS). I've implemented a proof of concept React application that uses https://github.com/IdentityModel/oidc-client-js and slightly modified react-oidc (that is a react wrapper to oidce-client-js), and it seems to work nicely with FA for me.