Using the credentials example from the readme results in a "missing type in composite literal" error.

reproducer: https://go.dev/play/p/0wt9cNVIheg

fix: define it like this

...
Config: &credentials.Config{
     ApiToken: os.Getenv("OPENFGA_API_TOKEN"), // will be passed as the "Authorization: Bearer ${ApiToken}" request header
},

see https://go.dev/play/p/n45oa0Rd4fZ

Description

Currently the Go-SDK will assert ulid is not well formed for empty string. Instead, it should allow.

Version of SDK

v0.2.0

Version of OpenFGA (if known)

v1.1.0

OpenFGA Flags/Custom Configuration Applicable

environment:
- OPENFGA_DATASTORE_ENGINE=postgres
- OPENFGA_DATASTORE_URI=postgres://postgres:password@postgres:5432/postgres?sslmode=disable
- OPENFGA_TRACE_ENABLED=true
- OPENFGA_TRACE_SAMPLE_RATIO=1
- OPENFGA_TRACE_OTLP_ENDPOINT=otel-collector:4317
- OPENFGA_METRICS_ENABLE_RPC_HISTOGRAMS=true

Reproduction

Detail the steps taken to reproduce this error, what was expected, and whether this issue can be reproduced consistently or if it is intermittent.

1. Initialize OpenFgaClient with openfga_sdk.ClientConfiguration parameter api_host=127.0.0.1, credentials method client_credentials
2. Invoke method read_authorization_models
3. See exception thrown

Sample Code the Produces Issues

<code snippet>

Backtrace (if applicable)

<backtrace>

Expected behavior

A clear and concise description of what you expected to happen.

Additional context

Add any other context about the problem here.

Related SDK Generator Issue: openfga/sdk-generator#114

Description

oauth2 package retains canonical import path from original code, causing packages importing it to substitute the original golang.org/x/oauth2 package instead.

the credentials package in this repo imports oauth2/clientcredentials which has the canonical import path set to golang.org/x/oauth2.

          This should be gone. Something is still generating this file

Originally posted by @rhamzeh in #28 (comment)

Related SDK Generator Issue: openfga/sdk-generator#115

Checklist

• I agree to the terms within the OpenFGA Code of Conduct.

Describe the problem you'd like to have solved

As a consumer of the SDK, I would like to hook it to my dashboards to get data on several metrics.

Describe the ideal solution

Integrate the OpenTelemetry Go API library https://github.com/open-telemetry/opentelemetry-go

Expose only from the inner OpenFgaApi. We need to be able to get these metrics:

• The latency of the request, split into
  • time it took since dev called the method until they get a response
  • time it took since the sdk issued a request to the API until it got a response
  • time reported by the server (query_duration_ms header)
• Response codes
• Error codes and method
• Method calls

See here for examples on usage:

• datastore query count in OpenFGA https://github.com/openfga/openfga/blob/4b47d50594b9c7e436d64cf783c0aedba30b940f/pkg/server/list_users.go#L95-L98
• other examples: https://github.com/open-telemetry/opentelemetry-go/tree/main/example/otel-collector

• Reduce the stutter of client invocations
  The underlying OpenFgaApi client interface should be embedded. For example,

  config, err := openfga.NewConfiguration(openfga.Configuration{...})
  if err != nil {
  // .. Handle error
  }
  
  apiClient := openfga.NewAPIClient(config)
  
  // current design
  stores, response, err := apiClient.OpenFgaApi.ListStores(context.Background()).Execute()
  
  // recommended design
  stores, response, err := apiClient.ListStores(context.Background()).Execute()

  It's possible to just store the underlying OpenFgaApi as a variable and use that, but that also requires a level of indirection that is unecessary. Point is - the APIClient should have the API methods attached to it directly, and this is best achieved by embedding the underlying interface.

  type APIClient struct {
      ...
  	OpenFgaApi OpenFgaApi
  }

  changes to

  type APIClient struct {
      ...
      OpenFgaApi
  }

• Make the API surface more idiomatic, streamlined, and RPC style

  The Go SDK is currently very verbose and not idiomatic. Building a Go integration with the OpenFGA Go SDK involved non-standard Go idioms, and this makes consuming the libraries API surface more challenging than other Go SDKs for other APIs.

  Our API is an RPC style API, and most Go clients that are idiomatic define client interfaces with request inputs and response outputs like so:

  type APIClientInterface interface {
      Read(ctx context.Context, req *ReadRequest) (*ReadResponse, error)
      Write(ctx context.Context, reqw *WriteRequest) (*WriteResponse, error)
  }

  In fact, if you look at the Go gRPC generated client stubs this is what generated code like this gets produced as. I acknowledge that our HTTP API defines custom mappings to our RPC API, and so we'd need to generate this structure off of the OpenAPI definition instead of inheriting the default HTTP-->gRPC transcoding mapping, but it would be nice to stay within this idiom.

  For example

  var client openfga.OpenFgaApi
  
  // current design
  readResp, httpResp, err := client.
    Read(context.Background()).
    Body(auth0fga.ReadRequest{...}).
    Execute() 
    
  // recommended design
  readResp, httpResp, err := client.Read(context.Background(), &auth0fga.ReadRequest{...})

• Drop the HTTP response param from the return list
  Our code currently returns the raw HTTP response as part of the method signatures. I suppose this isn't necessarily a bad thing, but it's definitely a Go idiom I have not particularly seen that used in the wild. I would also argue that exposing the raw HTTP response is counter productive to the Go SDK in the first place. The SDK is supposed to be abstracting the underlying HTTP API, and this makes it possible for client applications to build integrations they depend on with the raw HTTP API. That makes this part of the API surface another thing we have to maintain compatibility with even though the SDK is purposefully trying to abstract it.

  I recommend we drop the HTTP response object from the response altogether and depend upon the error usage pattern to appropriately capture the error semantics of the underlying HTTP response behavior. Lots of Go API client libs define an APIError structure and it implements the error interface, and they return this with the status and any underlying error message (if status is non 200). Also, if you need access to the Headers (for rate limiting for example), then it's also a common Go idiom to embed those in the response object.

  var client openfga.OpenFgaApi
  
  // current design
  readResp, httpResp, err := client.Read(context.Background()).Body(...).Execute()
  
  if httpResp.StatusCode != http.StatusOK {
    // handle error behavior
  }
  
  if remaining := httpResp.Header.Get("x-ratelimit-remaining"); remaining > 1 {
      // do next request, for example
  }
  
  // recommended design
  type APIErrorStatus int // enum set of codes for consummable API errors
  
  type APIError struct {
      ... // other metadata as needed
      Status APIErrorStatus
      Message string
  }
  
  type APIResponse[T any] interface {
      GetResponse() (T, error)
      GetHeaders http.Header
  }
  
  readResp, err := client.Read(context.Background(), &openfga.ReadRequest{...})
  if err != nil {
      if errors.Is(err, openfga.APIError) {
          // handle specific `APIErrorStatus`
      }
  }
  
  if remaining := readResp.GetHeaders()["x-ratelimit-remaining"]; remaining > 1 {
      // do next request, for example
  }

  A great example of a widely used Go SDK that follows some common Go idioms and is very easy to consume is the Stripe Go SDK (https://github.com/stripe/stripe-go). There are examples of this ^^ in that SDK.

Description

The OIDC authentication flow does not support token issuer urls containing a path, e.g. urls of Microsoft Entra ID.

Version of SDK

v0.3.0

Reproduction

fga client in version 0.2.1 (go-sdk v0.3.0) behaviour (replace and with your values):

$ fga store list --api-url http://localhost:8080 --client-id "$AZURE_CLIENT_ID" --client-secret "$AZURE_CLIENT_SECRET" --api-audience <api audience> --api-token-issuer "login.microsoftonline.com/<tenant id>"
Error: failed to initialize FGA Client due to Credentials are invalid: CredentialsConfig.ApiTokenIssuer (https://login.microsoftonline.com/<tenant id>) is in an invalid format

Expected behavior

API token URLs should support URLs with paths.

Additional context

The issue is caused by IsWellFormedUri function, which expects value to not contain path part.

Additionally, the value is used to build the final token URL value by adding a fixed /oauth/token path, which is not always a case - for example such URL in Microsoft Entra ID ends with either /oauth2/token or /oauth2/v2.0/token path.

Checklist

• I have looked into the README and have not found a suitable solution or answer.
• I have looked into the documentation and have not found a suitable solution or answer.
• I have searched the issues and have not found a suitable solution or answer.
• I have upgraded to the latest version of OpenFGA and the issue still persists.
• I have searched the Slack community and have not found a suitable solution or answer.
• I agree to the terms within the OpenFGA Code of Conduct.

Description

Hello,

I see that a recent change which then made it into 0.3.6 has caused a bump of Go from 1.21 to 1.21.9 but I can't figure out why.

This bump is preventing us from consuming 0.3.6 from within Incus as our base is still 1.21.

Expectation

Be able to build with Go 1.21.x

Reproduction

Build or consume go-sdk from a project using Go 1.21.x < 1.21.9.

OpenFGA SDK version

0.3.6

OpenFGA version

irrelevant

SDK Configuration

irrelevant

Logs

No response

References

No response

Our current models in the SDK Generator lead to a lot of if true statements (see: https://github.com/openfga/go-sdk/blob/main/model_authorization_model.go#L137).

We should update the generator to remove these statements.

Note that this change MUST be made in the generator templates https://github.com/openfga/sdk-generator/tree/main/config/clients/go/template

Description

NewSdkClient should return satisfy interface. The SdkClient's ReadAuthorizationModel should return SdkClientReadAuthorizationModelRequestInterface.

Version of SDK

Pre-release v0.2.2

Version of OpenFGA (if known)

N/A

OpenFGA Flags/Custom Configuration Applicable

N/A

Reproduction

1. Create a method where SdkClient interface is passed in as parameter
2. Try to call

		options := client.ClientReadAuthorizationModelOptions{
			AuthorizationModelId: openfga.PtrString(authorizationModelID),
		}
		model, err = fgaClient.ReadAuthorizationModel(context.Background()).Options(options).Execute()

See that this line fails to compile

Sample Code the Produces Issues

See above

Backtrace (if applicable)

N/A

Expected behavior

All methods should be callable.

Additional context

Add any other context about the problem here.

Description

When the authorization model id is an empty string, and ReadAuthorizationModel is called, it issues a request to:

GET /stores/<store_id>/authorization-models/""

leading to a 404

Version of SDK

latest on main

Version of OpenFGA (if known)

v1.2.0

Expected behavior

If authorization model id is "" when calling ReadAuthorizationModel, it should be treated as nil and throw an Authorization ID is required error
For all other requests, treat it as nil and read latest

Related SDK Generator Issue: openfga/sdk-generator#112

Description

Consider using https://pkg.go.dev/golang.org/x/sync/singleflight to wrap duplicate in-flight requests (excluding requests that alter system state).

Currently, some of the client interfaces return a struct (such as SdkClientGetStoreRequest). This does not allow easy testing / mocking with the SDKs.

For example,

type SdkClientGetStoreRequest struct {
	ctx    _context.Context
	Client *OpenFgaClient

	options *ClientGetStoreOptions
}

type SdkClientGetStoreRequestInterface interface{
	Options(options ClientGetStoreOptions) SdkClientGetStoreRequestInterface
	Execute() (*ClientGetStoreResponse, error)

    GetContext() _context.Context
    GetOptions() *ClientGetStoreOptions
}

Hello there,

Description

When using "paginable" methods, the HasContinuationToken() methods return true whereas there is no more page.

I expect the HasContinuationToken() method to return false in such cases.

As the openfga "paginable" endpoints always returns the continuation_token field (with an empty string value if there is no more page), the ContinuationToken response field is never nil (and so the HasContinuationToken() implementation always retrurn true).

Version of SDK

v0.2.2

Version of OpenFGA

v1.1.1

Reproduction

This issue can be reproduced consistently invoking any method querying an openfga "paginable" endpoint.

Here is an example using the ListStores method.

1. Initialize OpenFgaClient to point an openfga instance with N stores
2. invoke the ListStores()method with a page size > N
3. the response HasContinuationToken() should return false but it actually returns true

Sample Code that Produces the Issue

Another example relying on the continuation token to do something with all stores that creates an infinite loop because of the HasContinuationToken() method always returning true.

response, err := fgaClient.ListStores(context.Background()).Options(options).Execute()
if err != nil {
    return "", err
}
doSomethingWith(response.GetStores())

// infinite loop here because HasContinuationToken() always return true
for response.HasContinuationToken() {
    options.ContinuationToken = response.ContinuationToken
    response, err = fgaClient.ListStores(context.Background()).Options(options).Execute()
    if err != nil {
        return "", err
    }
    doSomethingWith(response.GetStores())
}

Expected behavior

The HasContinuationToken() method (on any response type) should return false if the response continuation_token field is an empty string

Related SDK Generator issue: openfga/sdk-generator#77

When using GoSDK with OpenFGAClient, if we call Write without options defined, SDK will crash due to null pointer. Root cause: WriteExecute tries to read auth model id even when options is null

Code snippet

	if request.options == nil || request.options.Transaction == nil || !request.options.Transaction.Disable {
		writeRequest := openfga.WriteRequest{
			AuthorizationModelId: client.getAuthorizationModelId(request.options.AuthorizationModelId),
		}
          ...
         }

Other endpoints also have the same problem as they read request.options.AuthorizationModelId directly without assertion whether request options is nil.

Description

The README example in Go-SDK uses inconsistent name.

Version of SDK

v0.2.2

Version of OpenFGA (if known)

N/A

OpenFGA Flags/Custom Configuration Applicable

N/A

Reproduction

The README example reads

body := ClientWriteRequest{
    Writes: &[]ClientTupleKey{ {
        User:     "user:81684243-9356-4421-8fbf-a4f8d36aa31b",
        Relation: "viewer",
        Object:   "document:roadmap",
    }, {
        User:     "user:81684243-9356-4421-8fbf-a4f8d36aa31b",
        Relation: "viewer",
        Object:   "document:budget",
    } },
    Deletes: &[]ClientTupleKey{ {
        User:     "user:81684243-9356-4421-8fbf-a4f8d36aa31b",
        Relation: "writer",
        Object:   "document:roadmap",
    } }
}

options := ClientWriteOptions{
    // You can rely on the model id set in the configuration or override it for this specific request
    AuthorizationModelId: openfga.PtrString("01GAHCE4YVKPQEKZQHT2R89MQV"),
}
data, err := fgaClient.Write(context.Background()).Body(requestBody).Options(options).Execute()

Notice that we declare variable as body while the execute refers to requestBody.

README has this inconsistent behaviour in a few places as well

Expected behavior

Should refer to body instead of requestBody.

Additional context

Add any other context about the problem here.

Have the following go-code

		body := &client.ClientReadChangesRequest{
			Type: selectedType,
		}
		options := &client.ClientReadChangesOptions{
			ContinuationToken: &continuationToken,
		}

		response, err := fgaClient.ReadChanges(context.Background()).Body(*body).Options(*options).Execute()

Capture from server sides shows that the body and continuation token not passed to the request

Description

In a lot of our deployments we use path based routing (e.g. example.com/serviceA proxies to service A, example.com/serviceB proxies to service B). It seems like the SDK does not support calling OpenFGA when it is exposed under a path (https://github.com/openfga/go-sdk/blob/main/utils.go#L336).

Reproduction

1. Initialize OpenFGA server
2. Use a reverse proxy to expose OpenFGA under a path
3. Try to make calls to the server through the proxy using the SDK

Expected behavior

We would like to be able to use the SDK to make calls to an OpenFGA server that is exposed under a path.

Checklist

• I have looked into the README and have not found a suitable solution or answer.
• I have looked into the documentation and have not found a suitable solution or answer.
• I have searched the issues and have not found a suitable solution or answer.
• I have upgraded to the latest version of OpenFGA and the issue still persists.
• I have searched the Slack community and have not found a suitable solution or answer.
• I agree to the terms within the OpenFGA Code of Conduct.

Description

README is broken after this code block. and it is caused by missing close tag at L931

Expectation

It supposes to look like this

Reproduction

Open github.com/openfga/go-sdk page and scroll to here

OpenFGA SDK version

0

OpenFGA version

0

SDK Configuration

0

Logs

No response

References

No response