Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

chore: Remove getIdentityByDID route #1558

Closed
wants to merge 4 commits into from

Conversation

dwertent
Copy link
Contributor

Overview

  • Fixed issues with rendering Swagger documentation.
  • Addressed some linter warnings.

Swagger Documentation Issue

The problem occurred when rendering the Swagger documentation. The code is designed to list API paths and generate documentation based on those paths. However, an issue arose in the way the Find function was used. This function is agnostic to the specific value of the API keys, which led to the swagger generator pulling in the wrong documentation.

Solution

I considered the following potential solutions:

  1. Implement a custom Find function that is aware of the API key value.
  2. Combine the API functions so that identities/{ID} can accept either a UUID or a DID.

I chose the second solution for the following reasons:

  1. A different organization maintains the Find function, and it may take time to implement a custom version.
  2. Since the API paths for handling DID and UUID are the same, it's logical to use a single function to handle both types of requests.

Side Note

I recommend deprecating DID support in favor of using UUIDs exclusively. This would simplify our API by providing a single, consistent definition for ID, reducing potential confusion and complexity in future development.

This PR fixes #1528

…Identity routes

The route parameter name "id" was updated in the getIdentityByID and patchUpdateIdentity routes to improve clarity and consistency.

Signed-off-by: dwertent <[email protected]>
@dwertent dwertent requested a review from a team as a code owner August 14, 2024 20:14
Copy link
Contributor

@EnriqueL8 EnriqueL8 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Based on your description the kin-openapi tool is not smart enough to differentiate between the same API paths but with different path parameters so the second one in the order will override the first one. In this case /identities/{did} overrides /identities/{iid} which results in the issue. You have decided to combine both those API calls into one generic /identities/{id}.

This introduces a slightly breaking change as the name of the path parameter is now different so the swagger will be different but the requests should still work. The description now is generic for both ID and DID.

The side note is not valid as DIDs are different to the IDs used internal by FireFly. A Decentralized identity (DID) is used to enable decentralised verification and is pinned on-chain, associated with a key. The IDs used here are purely a way for FireFly to uniquely identify in the DB the identities that this FireFly cares about and it's only present in the context of one single FireFly instance.

Comment on lines 381 to 384
as.namespacedContractSwaggerGenerator(hf, r, mgr, as.apiPublicURL, `/api/swagger.json`, ffapi.OpenAPIFormatJSON)
as.namespacedContractSwaggerGenerator(hf, r, mgr, as.apiPublicURL, `/api/openapi.json`, ffapi.OpenAPIFormatJSON)
as.namespacedContractSwaggerGenerator(hf, r, mgr, as.apiPublicURL, `/api/swagger.yaml`, ffapi.OpenAPIFormatYAML)
as.namespacedContractSwaggerGenerator(hf, r, mgr, as.apiPublicURL, `/api/openapi.yaml`, ffapi.OpenAPIFormatYAML)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to keep this change

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think it's just the linter is saying that the arguments are not being used in the function - ideally we fix the bug there and make it work properly, maybe not as part of this PR

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I will revert my changes and open an issue so we can address this later

@@ -300,7 +300,7 @@ func (as *apiServer) namespacedSwaggerUI(hf *ffapi.HandlerFactory, r *mux.Router
}))
}

func (as *apiServer) namespacedContractSwaggerGenerator(hf *ffapi.HandlerFactory, r *mux.Router, mgr namespace.Manager, publicURL, relativePath string, format ffapi.OpenAPIFormat) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here keep this

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This just seems to be a bug that the publicURL is maybe not used?

@@ -288,7 +288,7 @@ func (as *apiServer) nsOpenAPIHandlerFactory(req *http.Request, publicURL string
}
}

func (as *apiServer) namespacedSwaggerHandler(hf *ffapi.HandlerFactory, r *mux.Router, publicURL, relativePath string, format ffapi.OpenAPIFormat) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

probably better to fix the bug and not remove this

Comment on lines +70 to +72
func isDID(s string) bool {
return strings.HasPrefix(s, "did:")
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Keep the same level of check and change this to a regex expression - I think we should have one for DIDs already in the codebase

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since we have the DID validation happening later in the code, I preferred to determine if this a DID string or not. Because if this is a DID but a not valid one, I want the user to receive the proper error code (vs in this case the error code will be "unknown format"). wdyt?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah because you are not catching the error in the switch statement, you could catch the error there if you wish to? It just feels since you have moved the validation here make sense to construct the correct error instead of relying on the function underneath to throw the right thing - but will leave up to you

@@ -20,17 +20,19 @@ import (
"net/http"
"strings"

"github.com/google/uuid"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't use the google UUID library directly, use the one in firefly-common

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here, we are not validating the input, rather we are just filtering the input, so I didn't think we need to call the UUID validator with the context.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just more of a consistency and dependency thing to use the firefly-common library for this

@@ -107,7 +108,7 @@ var (
APIEndpointsGetGroupByHash = ffm("api.endpoints.getGroupByHash", "Gets a group by its ID (hash)")
APIEndpointsGetGroups = ffm("api.endpoints.getGroups", "Gets a list of groups")
APIEndpointsGetIdentities = ffm("api.endpoints.getIdentities", "Gets a list of all identities that have been registered in the namespace")
APIEndpointsGetIdentityByID = ffm("api.endpoints.getIdentityByID", "Gets an identity by its ID")
APIEndpointsGetIdentityByID = ffm("api.endpoints.getIdentityByID", "Gets an identity by its ID (UUID/DID)")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
APIEndpointsGetIdentityByID = ffm("api.endpoints.getIdentityByID", "Gets an identity by its ID (UUID/DID)")
APIEndpointsGetIdentityByID = ffm("api.endpoints.getIdentityByID", "Gets an identity by its ID or DID")

internal/syncasync/sync_async_bridge.go Show resolved Hide resolved
internal/apiserver/route_get_identity_by_id.go Outdated Show resolved Hide resolved
"github.com/hyperledger/firefly-common/pkg/ffapi"
"github.com/hyperledger/firefly-common/pkg/i18n"
"github.com/hyperledger/firefly/internal/coremsgs"
"github.com/hyperledger/firefly/pkg/core"
)

var getIdentityByID = &ffapi.Route{
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
var getIdentityByID = &ffapi.Route{
var getIdentityByIDOrDID = &ffapi.Route{

@dwertent
Copy link
Contributor Author

Summarizing your review:

  1. This PR should not break backward compatibility because iid/DID are not query params, mainly placeholders.
  2. I will revert unused code to the linter fixes I made.

@EnriqueL8
Copy link
Contributor

@dwertent build failing and e2e tests as well

@EnriqueL8
Copy link
Contributor

something wrong with the UUID verification restclient.go:118: <!! {"error":"FF00126: Unknown identity type: %!!(MISSING)s(MISSING)"}

@dwertent
Copy link
Contributor Author

This PR is no longer needed as we've resolved the issue with a different approach. I will open a new PR to update the FireFly-common tag once it's published.

@dwertent dwertent closed this Aug 16, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Swagger issue when working with identities
2 participants