To resolve this CloudFront conflict, you need to disassociate your custom domain from your CloudFront distribution.

Since AWS only allows one CloudFront distribution per hostname, and FusionAuth Cloud is implementing CloudFront on their infrastructure, you have two options:

Remove the custom domain from your CloudFront distribution — This allows FusionAuth to add the domain to their CloudFront distribution Set up your CloudFront as a proxy — Configure your distribution to proxy requests to FusionAuth's infrastructure

The recommended approach is to remove your custom domain from your CloudFront distribution entirely, as FusionAuth will handle CloudFront configuration as part of their cloud service.

How FusionAuth Custom Domains Work

When you configure a custom domain with FusionAuth Cloud, you create a CNAME record pointing from your custom domain to your deployment's durable URL (something like <random-string>.durable.fusionauth.dev). FusionAuth manages the CloudFront distribution and SSL certificates on their infrastructure, so you don't need to maintain your own CloudFront distribution for the custom domain.

The proper DNS setup should be:

Custom domain → CNAME → FusionAuth durable URL

This allows FusionAuth to provision and manage the entire CloudFront infrastructure, including SSL certificate validation and renewal, as part of their cloud service.

Related Documentation FusionAuth Cloud Custom Domains - Official guide for setting up custom domains on FusionAuth Cloud Adding a Custom Domain - Step-by-step walkthrough of the custom domain configuration process How to set up a Custom Domain for FusionAuth using AWS CloudFront - Guide for self-hosted FusionAuth installations (note: this is for self-hosted, not FusionAuth Cloud)

Note: If you're on a High Availability plan and want to use the Unlimited Custom Domains feature, or if you need assistance with the migration, open a support ticket.

Rollback Process for FusionAuth Cloud

For FusionAuth Cloud deployments, the rollback process must be handled by FusionAuth support—it is not something you can perform yourself.

Plan Eligibility and Backup Retention Business and High Availability (HA) Deployments: Upgrade backups are retained and available for 30 days Basic Deployments: Backups are not included, so rollbacks cannot be performed How to Request a Rollback

If you identify an issue after performing the upgrade:

Open a support ticket with FusionAuth The support team will perform the complete database rollback for you Expected Downtime

The rollback operation typically takes 20 minutes to 2 hours, depending on:

Database size How quickly the operations team can complete the rollback

Note that this involves a complete database rollback, so plan for 1-2 hours of downtime.

Support During Upgrades

For production upgrades, FusionAuth can provide:

An engineer on standby during your scheduled upgrade window An on-call support number for emergency assistance Pre-Upgrade Best Practices

Before upgrading to 1.69.1:

Review Release Notes for breaking changes, database migrations, and API modifications Choose an Upgrade Strategy: Incremental (version-by-version) for lower risk Direct upgrade for speed (but requires thorough testing) Test in Staging to verify: Authentication flows, webhooks, and APIs function correctly Templates render properly Database migrations complete successfully Coordinate with Support to schedule the upgrade and have assistance available if needed

@skorupa-pawel I saw this on Firefox in the past but never on Safari.

Does this apply to all applications?

Do you have a logout url configured in the OAuth tab? Does that URL exist?

@shyamsundar-k said in How to generate and authorized java spring controller using JWT:

We need to pass the token in the API header as Authorization: Bearer<token> But what is the process so that I can validate the endpoint with the valid token if the token is invalid or does not have the required roles or scope then I should get 401 else I should be able to access the API successfully.

Once you have a token in your API, you can validate it in two different ways. But it's worth noting that to validate the token, you must validate the signature and then the claims.

First option: use a library to validate the signature. Most languages have options. For java, you can use fusionauth-jwt, the readme has sample code.

Second option: use the validate API. You could use the FusionAuth client library to make this call if you'd like.

The first means you have to pick a library. The second means you have to make a network call.

Either way, after you validate the signature, you need to check the claims (issuer, audience, expiration, custom claims) to make sure they are what you expect.

Here's more about how to consume a JWT.

@bhardwajmunish88 From the stackoverflow link:

According to this github issue this is corrected by using docker 20.10.5.

Can you try with a later version of Docker? I think this is due to the Java Docker image, and isn't an issue with FusionAuth.

If a user is still receiving a SearchEngineRequestFailedException after a system reindex and patching, there could be several reasons for this.

Firstly, the issue may not have been related to the index or patching, but rather a problem with the user's search query or the way they are interacting with the system.

Alternatively, it could be that the reindex and patching process did not fully resolve the underlying issue, and further investigation or troubleshooting is necessary.

It's also possible that there are other technical or environmental factors at play that are causing the exception to continue occurring. In any case, it may be necessary to consult with technical support or seek out additional resources to diagnose and resolve the issue.

ok main thing is, is it ok to use header ES256 for jwt created using secp256k1 keys?

https://datatracker.ietf.org/doc/html/rfc8812 says, secp256k1 curve should only be used with ES256k header, but in authfusion even if we give k1 pair keys and then use sign and encode a JWT using EC, it will come as ES256 only, is that okay?

Another doubt is, those jwt (k1 curve keys + ES256) created in authfusion is only able to verify in jose4j with .setRelaxVerificationKeyValidation() //needed if the key is smaller than 256 bits.

Without it we get the error:

JWT processing failed. Additional details: [[17] Unable to process JOSE object (cause: org.jose4j.lang.InvalidKeyException: ES256/SHA256withECDSA expects a key using P-256 but was null):

Description inside setRelaxVerificationKeyValidation :

Bypass the strict checks on the verification key. This might be needed, for example, if the JWT issuer is using 1024-bit RSA keys or HMAC secrets that are too small (smaller than the size of the hash output)

Is it the correct way to validate jwt created using ec in authfusion?

Solution:

https://github.com/FusionAuth/go-client/issues/48

Proxy servers can store cached copies of sites. You will get the data from the proxy when you access a particular location.

@garveymozga33 Thanks for your feedback. The basic cloud plan does not currently include backups and is not intended for production use.

Generally speaking, the provisioning depends greatly on the infrastructure being requested as well as the current demands placed on the underlying cloud infrastructure provider.

For smaller deployments, you can expect a 5 to 10 minute timeline. For a setup more aligned with a high-volume system with large CPU and database capacities, you can expect a provisioning time of 20 to 45 minutes.

Yes, you could connect one FusionAuth to another using an OpenID Connect Identity Provider or SAML v2.

Seems like the library I used is opinionated. Thanks for the hints.

yeah, pretty simple really, if you want to try it yourself before my tutorial is out, try using the hasura cloud + Auth0 tutorial on Hasura's site, and use the lessons from that to use it with fusionauth.