chore: Remove getIdentityByDID route#1558
Conversation
Signed-off-by: dwertent <david.wertenteil@kaleido.io>
…Identity routes The route parameter name "id" was updated in the getIdentityByID and patchUpdateIdentity routes to improve clarity and consistency. Signed-off-by: dwertent <david.wertenteil@kaleido.io>
EnriqueL8
left a comment
There was a problem hiding this comment.
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.
| 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) |
There was a problem hiding this comment.
We need to keep this change
There was a problem hiding this comment.
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
There was a problem hiding this comment.
I will revert my changes and open an issue so we can address this later
| })) | ||
| } | ||
|
|
||
| func (as *apiServer) namespacedContractSwaggerGenerator(hf *ffapi.HandlerFactory, r *mux.Router, mgr namespace.Manager, publicURL, relativePath string, format ffapi.OpenAPIFormat) { |
There was a problem hiding this comment.
This just seems to be a bug that the publicURL is maybe not used?
| } | ||
| } | ||
|
|
||
| func (as *apiServer) namespacedSwaggerHandler(hf *ffapi.HandlerFactory, r *mux.Router, publicURL, relativePath string, format ffapi.OpenAPIFormat) { |
There was a problem hiding this comment.
probably better to fix the bug and not remove this
| func isDID(s string) bool { | ||
| return strings.HasPrefix(s, "did:") | ||
| } |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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
| "net/http" | ||
| "strings" | ||
|
|
||
| "github.com/google/uuid" |
There was a problem hiding this comment.
We don't use the google UUID library directly, use the one in firefly-common
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
just more of a consistency and dependency thing to use the firefly-common library for this
| 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)") |
There was a problem hiding this comment.
| 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") |
| "github.com/hyperledger/firefly/pkg/core" | ||
| ) | ||
|
|
||
| var getIdentityByID = &ffapi.Route{ |
There was a problem hiding this comment.
| var getIdentityByID = &ffapi.Route{ | |
| var getIdentityByIDOrDID = &ffapi.Route{ |
|
Summarizing your review:
|
Signed-off-by: dwertent <david.wertenteil@kaleido.io>
Signed-off-by: dwertent <david.wertenteil@kaleido.io>
|
@dwertent build failing and e2e tests as well |
|
something wrong with the UUID verification |
|
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. |
Overview
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
Findfunction 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:
Findfunction that is aware of the API key value.identities/{ID}can accept either a UUID or a DID.I chose the second solution for the following reasons:
Findfunction, and it may take time to implement a custom version.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