Specific realm configuration for the tests?

[Skyppid]

Since we upgraded to Keycloak 23 a feature broke. Not sure if it's an issue of the library or breaking changes in Keycloak. Since this repository seems to be rather abandoned and I don't have time to wait for approval and a new Nuget package, I forked it and upgraded it to .NET 8 and Flurl 4 at that.

So far so good, it compiles and there are likely no breaking changes involved. Yet 36 tests fail. The question is: Did you use a specific realm.json configuration for the tests? I created an "Insurance" realm on my local Keycloak but that doesn't help.

I hope you can give me a hint. Once I can verify that the actual logic still works I'd like to add the missing endpoints we need to hopefully fix our issue as it's urgent.

I usually get errors like

Call failed with status code 401 (Unauthorized): POST http://localhost:8080/realms/Insurance/protocol/openid-connect/token

Which leads me to believe that maybe the client settings for admin-cli might not be correct for a default realm configuration? Not sure, not that deep into it. Maybe you can help :)

[societ-campbellwray]

Hi @Skyppid

Apologies for any issues you have been experiencing, fortunately I have some good news for you, this repo hasn't been abandoned, we just don't have the resources to keep it up to date with every change that Keycloak makes, so a lot of our contributions come from PRs created by users like yourself.

Unfortunately this repo has been abandoned a few times, and we're the 3rd team to pick it up, with this comes a lot of lost knowledge, and as a result I have never been able to successfully get the unit tests to pass. I tried to get it working a while back but, like you, found that they expect a very specific Keycloak configuration, presumably this was based on the original creator of this library's specific Keycloak use case.

It would be hugely appreciated if you could open a PR with your changes, I would be happy to merge it in and do a deployment today. As for the unit tests, for the reasons stated above I am ok if we simply ignore the failing unit tests, and we can resolve any issues if/when they arise.

Thanks,
Campbell

[societ-campbellwray]

Sorry @Skyppid I missed your edit.

It's a little hard to tell whether the changes you have made are too extreme or if the refactoring is reasonable without seeing the changes.

As for the rest of it

• .NET 6 is reaching EOL in November, so I think that change makes sense.
• I had originally skipped the Flurl 4.0 upgrade as it moves from Newtonsoft to System.Text.Json, so it is a fairly major change and will almost certainly break compatibility for existing users, but I'm not opposed to it if it is a helpful change.

I'd like to avoid having too many public forks if possible, as it does make it confusing for people starting out with Keycloak to know where to go, so I think it makes sense to open the PR, and we can revert some of the refactoring if it is too extreme, but I'm sure it is fine.

Thanks again,
Campbell

[Skyppid]

Hi @sps-campbellwray,

So I just finished the reworks necessary. I'm sorry in advance as I didn't know that if I pushed to our company repository this also pushes to the official NuGet feed and thus the prerelease is now part of your package. Wasn't expected but since it's prerelease it shouldn't be too problematic I hope (except for it being v23 now).

Since the issue was pressing on our side and had to be fixed (and it got confirmed here, that it is indeed due to changes to the endpoint that might not have been marked as breaking changes or overlooked by us when upgrading) I couldn't wait to polish this to make a PR and let you publish it. We need to do our tests tomorrow and this was a blocking issue.

You can decide if you want to adapt what I changed:

• Upgraded to .NET 8 (as you said, 6 is deprecated soon and .NET 8 is the latest LTS)
• Refactored to a more modern C#12 based code (primary constructors, file-scoped namespaces, etc.) - non-breaking
• Added Microsoft.Extensions.Logging and added request and response logging to it (default: off)
• Deployment via GitHub Actions
• Added GitTools/GitVersion for automatic semantic versioning of packages
• Version set to 23 (to match the current Keycloak version, makes it easier for developers - though a check would be necessary which APIs currently are missing)
• Added the new /groups/{id}/children endpoint as GetSubgroupsAsync(...) which is needed to actually get sub-groups now

Like I said, I'm sorry that I polluted your feed - but I'm open to cooperation if you want to take all or some of the changes into your repository now that we have a functional version to start with.

By the way I can confirm that everything works (at least what we use it for). It would be beneficial to fix the unit tests though.

I had originally skipped the Flurl 4.0 upgrade as it moves from Newtonsoft to System.Text.Json, so it is a fairly major change and will almost certainly break compatibility for existing users, but I'm not opposed to it if it is a helpful change.

About that: I upgraded it but Flurl 4 offers a backwards-compatibility via another package I used. So for now the library still relies on Newtonsoft as it would require a lot of endpoints to be refactored (loss of dynamic support) which would end in plenty of potential bugs that are not yet covered by UTs.

So the whole upgrade is basically safe as far as I can tell.

I get your concern about the forks. I'm okay with merging the changes as soon as it's polished and we agreed on what changes are fine. Then I can delete the fork. I just needed a functional version with the new endpoint (yes, the upgrade was unnecessary for that but I guess my inner perfectionist got the upper hand on that).

PS: You can check the diff yourself here: https://github.com/CarbonFreed-AI/Keycloak.Net/tree/feature/major-upgrade

EDIT: Seems like there's just something off with my nuget configs. Not sure where Visual Studio gets that package from as the feed is not configured but on nuget it doesn't show my version. Would have been suprised if it actually got published to Nuget.org

Best regards,
Manuel

[societ-campbellwray]

Hi @Skyppid,

I suspect the NuGet thing might just be the Package Manager combining packages from different sources (nuget.org and your private NuGet server) into a single item, because I agree, it doesn't look like anything changed on nuget.org.

I took a look at your fork/branch and it all looks fine, it seems like 99% of the changes are due to the change to file scoped namespaces, but overall I would agree it doesn't look like there is anything breaking (although it's quite hard to find changes across 263 files).

The one thing that I wasn't sure about was HttpCompletionOption.ResponseContentRead, is this fixing a bug, or are you just explicitly setting the default option?

I'll also admit that I don't know a whole lot about GitHub actions, as our company primarily uses Bitbucket, but it would be nice to have the build/deploy process automated. I don't know whether it makes sense to exclude that for the time being, since I'm not entirely sure what would be required to make it work with nuget.org, or how to set it up to automatically create GitHub versions.

Other than that, I'd agree that it makes sense to merge this into this project, and to do another release, I also don't have any issues changing the versioning scheme or anything like that.

Thanks,
Campbell

[Skyppid]

The one thing that I wasn't sure about was HttpCompletionOption.ResponseContentRead, is this fixing a bug, or are you just explicitly setting the default option?

That's due to Flurl 4's changes - it now requires this parameter in between. There might be room for optimization for some calls which do not expect any content, but due to "not implement potential bugs" I passed and used the default that will always work.

I'll also admit that I don't know a whole lot about GitHub actions, as our company primarily uses Bitbucket, but it would be nice to have the build/deploy process automated. I don't know whether it makes sense to exclude that for the time being, since I'm not entirely sure what would be required to make it work with nuget.org, or how to set it up to automatically create GitHub versions.

Shouldn't be too difficult. I think for public repositories it might even be free or at least a company usually has 3000 mins included in their paid plan. You just need to push to nuget.org as source instead of the GitHub company feed. I might be able to apply the changes if you wish so, but it's gonna be hard for me to fix since I can't access your repository.

The versioning is done through Git. I'm not sure if the default config for GitVersion is fine for this repository, but basically by creating a release branch and merging it via PR it should automatically increment the version. See this for a detailed explanation. Basically with each commit the version increments. For certain branches (or if manually done via commit message) the minor and major version can be incremented.

Thus I'd release it as 23-prerelease and mention that in the README that this version is updated but not yet production ready (since certainly some APIs for 23 are missing).

[Skyppid]

So by now I also enabled nullable support, fixed those few parts that needed fixing (most was just search and replace for thousands of string param = null occurences). I'll test the new version tomorrow with our software. With that it's completely modernized and I eliminated all warnings that came up (except for the obsolete ones that are misused for "not implemented").

Once I can verify that all works as expected I can make some finishing touches to make the PR. I can modify the workflow file so that you can use it with a few changes to it if you wish.