@dan Yes, a production server setup would be great. At this point the product will be freemimum so the finances are a little tight :). The problem with a load balancer is that a user must login into the same copy of FA every time. But this won't be possible if a load balancer is deciding which instance to send a user to. Unless I should use RDS as the FA database? Has anyone done this successfully?

This would let you, for example, send different requests based on domain name to different tenants.

That view shows the last 10 logins, and you can paginate through all logins for that user.

That should show all logins for a user, but you have to page through. You can also use the System > Login Records screen and search for the user and then see all login records.

That should give you the same results from the Manage User > Recent Logins.

@tarun-verghis Ensure your database is listening on a valid IP and that you have the ability to connect to it using username/password. This is usually configured in the pg_hba.conf file and requires a line like:

host all all 127.0.0.1/32 md5

If you only have lines that say trust then FusionAuth won't be able to connect since it doesn't support local sockets or local connections.

Great!

Note that you can also change the FusionAuth tutorial to use a different environment variable for the client secret.

You should read the FusionAuth license, or, rather, have your employers do so.

We've also created a license FAQ which answers common questions about FusionAuth usage. I think this is the relevant section:

I sell downloadable software that contains FusionAuth. What type of license do I need?

And the answer:

You will need a reseller license for FusionAuth in order to resell it to your customers. This license is usually charged per customer rather than per monthly active user. You should contact our sales team to discuss licensing options. They can be reached at sales@fusionauth.io.

@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.

What does the error event log say? Have you turned on idp debugging? Does this occur with only one apple id, or with all of them?

Have you ensured that your client secret and client id don't have extra whitespace on either side?

Have you looked at the other apple id posts in the forum?

This one looks like it has some useful info: https://fusionauth.io/community/forum/post/1286

Did you register the new user with the application?

This doc talks about the two different concepts of authentication and authorization in the context of FusionAuth: https://fusionauth.io/docs/v1/tech/core-concepts/authentication-authorization/

Can you please provide more details?

What you are trying to do? A step by step explanation would be really helpful for anyone trying to understand what problem you ran into.

Thanks,
Dan

At this point, you may also consider creating a KickStart script that loads the basic configuration with mentioned API keys, groups etc. into a fresh FA installation. You've mentioned that you are working on a test installation, so during the further tests you will probably fill it again with new test data entities. If so, it will most likely be easier to recreate the FA with basic configuration via KickStart, rather than to pick unnecessary entities and delete them one by one. Such script also stands as a good documentation on what configurations has been made to meet your environment requirements.

This post may be a bit off the topic, but from my experience such approach quickly pays off, so you can at once solve your issue and boost up your testing environment ergonomics.

Looks like this was a regression and based on the github issue a fix should be released in 1.23.4. Sorry about that!

@muralimaxk

I'm not sure I understand what you are saying. Can you give me a bit more detail?

@robertom

I'm not quite sure how to answer your question without more details. If you want to use FusionAuth as an external directory, you could encrypt sensitive data and store it on the user or registration objects. While there is built in support for managing keys you'd have to build the actual encryption logic yourself; you can't mark a user field to be 'extra encrypted' in FusionAuth at this time.

That might be an interesting feature; feel free to file a feature request with more details.

I think @mgetka makes some good points. I'm afraid I don't have enough detail to provide an authoritative answer. From what you've said, I think you could do this with roles, application registrations, groups or even user actions. You could for example, have three different groups of roles (they are just strings, and you can add more than one to a user):

... team1_member team2_member ... position1_holder position2_holder ... access_perm_1 access_perm_2 ...

I guess it also depends on how you want to consume these. Are you going to be looking up the user via FusionAuth API calls? Or will you want this embedded in a JWT for portable claims?

In the former case (API calls) you can make multiple calls and learn a lot about the user.

In the latter case, even though you have the JWT populate lambda, it is limited to what is on the user and registration objects.

So you couldn't, for example, know the group name (though I believe you have the group id) in the lambda, so you couldn't put it in the JWT. More on this issue.

@cyrill-lippuner

Hmmm. The docker-compose you shared shows you are still in development mode: FUSIONAUTH_APP_RUNTIME_MODE: development.

Not sure if this is a typo, but you want to be in production mode, not productive mode. (Although we all want to be productive ).

Can you please try with FUSIONAUTH_APP_RUNTIME_MODE: production and share what the results are?

While FusionAuth supports both well, if you have the option to use SAMl v2 or OIDC, I would always recommend OIDC.

In general, it is much much simpler to use, debug, configure, etc.