@dan

I don't think it is the file size as such. We have a flickering CI run now, where sometimes everything is fine, and other times it seems the kickstart didn't run at all. (at this point we have not collected the logs from the CI server, but that something I will only be able to get to by easiest next week.

We have seen similar issues locally, but not something that we can repeat 100% of the time.

When polling we poll for something like this: https://DOMAIN/api/application/UUID/oauth-configuration Because that indicates if the essential parts of the kickstart file actually ran AND can be run without any auth information. We do this for up to 60 times, with a 1 second network timeout.
Depending on how Fusionauth handles client interrupted connections, it could be that we are flooding it that way?

In regards to the web hook or async notification on kickstart finalisation. That would not be the easiest to use. We use Cypress, and it would be difficult to tie that together.
The best experience would be to have Fusionauth NOT accept incoming request until the Kickstart sequence is done, and fail to boot entirely if the kickstart failed.
I can imagine that this is probably asking a lot, so a compromise would be some lightweight endpoint where we can ask the Kickstart status: some http endpoint that replies with will_not_kickstart (eg when there is already a config), waiting_to_kickstart, kickstart_running, kickstart_success, kickstart_failed.

Polling for a lighter weight object would be possible. I'm not the biggest fan of the lambda check as it requires the CI runner to know the API access token. Anything else you could suggest?

We are running this in Github CI, inside a docker-compose setup. Again, we don't have the logs yet. This will take us a week or so to get.

I'll get back here as soon as I have more info.

We are using FusionAuth in a greenfield product. One of the main reasons we are using FustionAuth is the ability to use an isolated version in CI and development. Using the Kickstart file here is important, as it allows us to easily test new configurations.

However, we have noticed our test starting to fail more and more due to Fusionauth not being configured. This is related to the size of the kickstart itself. (eg, introducing Themes in the kickstart file completely break the end to end tests). This failure is always related to the client/application not being configured.

Fusionauth becomes available before the Kickstart process is completed. Worse, it remains available after the Kickstart process failed. This basically means we don't know if/when it is ready to be used int the tests.

We thought about fixing this by polling for the oauth configuration endpoint before running the tests. This works, sometimes, but it seems that this polling overloads the server and the Kickstart process fails with timeouts.

Is there any best practice we can consider with the kickstart file, how to know if and when it completed? Our only other option we see is to dump the Database after locally running the kickstart process, and use that as the basis for our end to end tests, but that would bring an entire other set of problems with it.

Would appreciate any help here.

Hi,

I know this request has probably arrives several times a year - in fact I read in the blog - but here is my take on it.

Wildcards should be allowed in authorizedRedirectURLs. That is to say sub-domain based wildcards should be allowed.

Our use case: We have a multi tenant application with a single user base. Each client is identified by a domain. in 80% of the cases this a subdomain of the main domain of our application (ex: customer.example.com). Other client have their dedicated domains.

For this setup it would be ideal if we could set up https://*.example.com/redirect as an entry in authorizedRedirectURLs. I know you think this to be unsafe, I've read it:

However, allowing such wildcard matching for the redirect URI is a security risk. If the redirect URI matching is flexible, an attacker could redirect a user to an open redirect server controlled by them, and then on to a malicious destination; OWASP further discusses the perils of such open redirect servers. While this would require compromising the request in some fashion, using exact matching for redirect URIs eliminates this risk because the redirect URI is always a known value.

But I think an exaction fo this should be allowed. The lack of this can create both less safe and broken applications. Let me explain:

If we want to update authorizedRedirectURLs with the new domain, we could. However as there is no API to add or remove entries from this list, we run the risk that in a high concurrency situation we get in a state where not all URL's are in the list. We must also be aware of the size limits of this list (if there is any).

An alternative solution would be too redirect to a single endpoint in our control. This endpoint then does the final redirect. However, this is just moving the security problem. Now this endpoint must validate the redirect domain and path.
There is a good chance that as a developer we might do this poorly or at least worse than FusionAuth could.

So, to summarise:

Subdomain wild cards should be allowed in authorizedRedirectURLs to deal with application that use subdomains to identify their clients.