fix: avoid nil interface panic on Keycloak config discovery

[pulkitvats2007-crypto]

Description

• Fixes a critical runtime panic in GetKeycloakURL() when interacting with a Microcks server that has Keycloak disabled.
• Previously, the CLI performed unconditional type assertions on auth-server-url and realm fields, which are absent when the /api/keycloak/config endpoint returns { "enabled": false }. This caused a fatal panic:
  panic: interface conversion: interface {} is nil, not string.
• Updated logic to first check the enabled flag and only access Keycloak-specific fields when it is true.
• Ensures the CLI returns "null" safely when Keycloak is disabled instead of crashing.

Implementation Details

enabled := configResp["enabled"].(bool)

if enabled {
    authServerURL := configResp["auth-server-url"].(string)
    realmName := configResp["realm"].(string)
    return authServerURL + "/realms/" + realmName + "/", nil
}
return "null", nil

Testing & Prevention

• Added unit tests in pkg/connectors/microcks_client_test.go using httptest.Server.
• Covered both scenarios:
  • Keycloak enabled → validates correct URL construction.
  • Keycloak disabled → verifies no panic and correct "null" return.
• All tests pass successfully.

Impact

• Prevents fatal runtime crashes during CLI operations such as:
  • microcks login
  • microcks test
  • Token refresh flows
• Enables seamless usage of the CLI with Microcks deployments where Keycloak is intentionally disabled (common in local setups and CI/CD pipelines).
• Eliminates a class of interface conversion panics caused by unsafe type assertions on missing JSON fields.
• Improves overall CLI robustness and production reliability.

---

Related issue(s)

Fixes #267

[github-actions]

👋 @pulkitvats2007-crypto

Welcome to the Microcks community! 💖

Thanks and congrats 🎉 for opening your first pull request here! Be sure to follow the pull request template or please update it accordingly.

Hope you have a great time there!

[github-actions]

This pull request has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 30 days if no further activity occurs. To unstale this pull request, add a comment with detailed explanation.

There can be many reasons why some specific pull request has no activity. The most probable cause is lack of time, not lack of interest. Microcks is a Cloud Native Computing Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this pull request forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️

[Vaishnav88sk]

Why return the string "null" and not just ""? Is something downstream actually expecting the literal string "null"? A comment here would help a lot.

[Vaishnav88sk]

@pulkitvats2007-crypto
Need a rebase, and resolve conflicts

[Vaishnav88sk]

This is still an unchecked type assertion. If the enabled key is missing or "enabled": null in the response, this line panics; exactly the class of bug this PR is meant to fix.

Suggested change

	enabled := configResp["enabled"].(bool)
	enabled, ok := configResp["enabled"].(bool)
	if !ok || !enabled {
	return "null", nil
	}

[Vaishnav88sk]

minor typo: "disables" to "disabled"

[Vaishnav88sk]

Tests cover enabled/disabled but not the missing-enabled-key case that the comma-ok fix addresses.

[Harsh4902]

@pulkitvats2007-crypto I Agree with @Vaishnav88sk's review, can you please have look?

[Caesarsage]

As per my comments here

#267 (comment)

I believe this can be closed. You will notice merge conflicts