Is your feature request related to a problem? Please describe.
Currently, the gocloak package provides various utility functions for interacting with Keycloak. However, it does not provide a straightforward way to retrieve the endpoints that are constructed and used within these functions. This is an issue when developers need to access the raw endpoints for debugging, logging, or for use with different HTTP clients or custom request handling.
Describe the solution you'd like
I propose adding a complementary function for each existing utility function that returns the endpoint as a string. For instance, alongside the existing LoginAdmin function, a LoginAdminEndpoint function could be introduced:
The existing function would then utilize this new endpoint function:
func (client *gocloak) LoginAdmin(username, password, realm string) (*JWT, error) {
loginPath := client.LoginAdminEndpoint(username, password, realm)
// ... rest of the function
}
Describe alternatives you've considered
An alternative could be to provide a separate utility structure or function map where endpoints are stored and can be referenced. However, this might add unnecessary complexity compared to the straightforward approach of simply having corresponding endpoint functions.
Additional context
This feature would greatly benefit developers who require access to the raw endpoints for custom use cases such as:
Logging the endpoints for monitoring requests and debugging.
Using the endpoints with different HTTP clients or custom middleware.
Providing the capability to extend the client's functionality without modifying the gocloak source.
No additional context or screenshots are provided at this time, but I am happy to discuss this further and provide examples if needed.
Is your feature request related to a problem? Please describe. Currently, the gocloak package provides various utility functions for interacting with Keycloak. However, it does not provide a straightforward way to retrieve the endpoints that are constructed and used within these functions. This is an issue when developers need to access the raw endpoints for debugging, logging, or for use with different HTTP clients or custom request handling.
Describe the solution you'd like I propose adding a complementary function for each existing utility function that returns the endpoint as a string. For instance, alongside the existing LoginAdmin function, a LoginAdminEndpoint function could be introduced:
The existing function would then utilize this new endpoint function:
Describe alternatives you've considered An alternative could be to provide a separate utility structure or function map where endpoints are stored and can be referenced. However, this might add unnecessary complexity compared to the straightforward approach of simply having corresponding endpoint functions.
Additional context This feature would greatly benefit developers who require access to the raw endpoints for custom use cases such as:
No additional context or screenshots are provided at this time, but I am happy to discuss this further and provide examples if needed.