feat(all): Add scopes in OpenAPI files #1700
Conversation
|
Warning Rate limit exceeded@flemzord has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 13 minutes and 41 seconds before requesting another review. How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. WalkthroughThe pull request introduces significant changes to the build process in the Changes
Possibly related PRs
Suggested reviewers
Poem
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files ignored due to path filters (13)
components/ledger/openapi.yamlis excluded by!**/*.yamlcomponents/ledger/openapi/v1.yamlis excluded by!**/*.yamlcomponents/ledger/openapi/v2.yamlis excluded by!**/*.yamlcomponents/payments/openapi.yamlis excluded by!**/*.yamlee/auth/openapi.yamlis excluded by!**/*.yamlee/orchestration/openapi.yamlis excluded by!**/*.yamlee/orchestration/openapi/v1.yamlis excluded by!**/*.yamlee/orchestration/openapi/v2.yamlis excluded by!**/*.yamlee/reconciliation/openapi.yamlis excluded by!**/*.yamlee/search/openapi.yamlis excluded by!**/*.yamlee/wallets/openapi.yamlis excluded by!**/*.yamlee/webhooks/openapi.yamlis excluded by!**/*.yamlreleases/base.yamlis excluded by!**/*.yaml
Files selected for processing (2)
- Earthfile (3 hunks)
- releases/sdks/go/.speakeasy/gen.lock (1 hunks)
Files skipped from review due to trivial changes (1)
- releases/sdks/go/.speakeasy/gen.lock
Additional comments not posted (2)
Earthfile (2)
55-57: Simplified OpenAPI build process enhances efficiencyThe new
BUILDcommands in theopenapitarget replace manual loops, simplifying the build process and improving maintainability.
97-98: Consistent build process for all componentsAdding
BUILDcommands for both./componentsand./eedirectories in thebuild-alltarget ensures that all components are built consistently.
flemzord
force-pushed
the
feat/add-scopes-in-openapi-spec
branch
2 times, most recently
from
e0cb7a3
to
f0653d8
Compare
There was a problem hiding this comment.
Actionable comments posted: 9
Outside diff range and nitpick comments (23)
releases/sdks/go/USAGE.md (1)
16-16: Consider standardizing indentation in code examples.The linter has flagged a hard tab on this line. While this is technically correct, it's worth noting that the entire code example appears to use tabs for indentation.
To maintain consistency within this code example, we should either:
- Keep the current tab indentation throughout the example, or
- Convert all indentation in this example to spaces.
Additionally, it might be beneficial to make a global decision on the preferred indentation style (tabs vs spaces) for all code examples in the documentation. This would ensure consistency across all SDK usage examples.
Tools
Markdownlint
16-16: Column: 1
Hard tabs(MD010, no-hard-tabs)
releases/sdks/go/docs/pkg/models/shared/security.md (1)
8-10: Add examples for new fieldsThe
Examplecolumn is empty for the new fields (ClientID,ClientSecret,TokenURL). Adding examples would help users understand the expected format and usage of these fields.Consider adding appropriate examples, such as:
-| `ClientID` | **string* | :heavy_minus_sign: | N/A | | -| `ClientSecret` | **string* | :heavy_minus_sign: | N/A | | -| `TokenURL` | **string* | :heavy_minus_sign: | N/A | | +| `ClientID` | **string* | :heavy_minus_sign: | N/A | "your-client-id" | +| `ClientSecret` | **string* | :heavy_minus_sign: | N/A | "your-secret" | +| `TokenURL` | **string* | :heavy_minus_sign: | N/A | "https://api.example.com/oauth/token" |releases/sdks/go/pkg/models/shared/security.go (2)
9-14: LGTM: Security struct updated for OAuth2 client credentials.The changes to the
Securitystruct align well with the shift to OAuth2 client credentials. The struct tags are correctly formatted and provide necessary metadata.Consider making the
tokenURLfield exported (capitalize the first letter) if it's intended to be accessed outside this package. If it's meant to be internal, the current implementation is correct.
20-24: LGTM: UnmarshalJSON method added correctly.The
UnmarshalJSONmethod is correctly implemented to satisfy thejson.Unmarshalerinterface.Consider simplifying the error handling:
func (s *Security) UnmarshalJSON(data []byte) error { return utils.UnmarshalJSON(data, &s, "", false, false) }This change removes the unnecessary if statement since the function already returns the error from
utils.UnmarshalJSON.releases/sdks/go/docs/sdks/formancesearchv1/README.md (2)
29-29: LGTM! Consider updating the surrounding documentation.The change from
AuthorizationtoClientIDin the SDK initialization is correct and aligns with the updated authentication method. This improves security by using a client ID instead of an authorization token.Consider updating the surrounding documentation to reflect this change in authentication method, explaining the shift from authorization tokens to client IDs and providing guidance on how to obtain and use the client ID.
Line range hint
1-124: Suggestion: Conduct a comprehensive review of the entire document.While the code examples have been correctly updated to use the new
ClientIDauthentication method, it's important to ensure that the rest of the document aligns with this change.Consider reviewing:
- Any textual descriptions of the authentication process.
- The parameter tables for each operation to ensure they reflect the new
ClientIDparameter if applicable.- Any other sections that might reference the old
Authorizationmethod.This will ensure that the entire document is consistent and up-to-date with the new authentication approach.
releases/sdks/go/docs/sdks/formancereconciliationv1/README.md (1)
373-373: Authentication change consistently applied across all examplesThe security configuration update from
AuthorizationtoClientIDhas been consistently applied in this final example as well.The change maintains consistency across all examples in the README.
Given that this change has been applied consistently across all examples in the README:
- Ensure that this change is reflected in the actual SDK implementation, not just the documentation.
- Update any related documentation, such as API references or getting started guides, to reflect this new authentication method.
- Consider creating a migration guide for existing users to transition from the old
Authorizationmethod to the newClientIDmethod.- Review and update any CI/CD pipelines or automated tests that might be using the old authentication method.
These steps will help ensure a smooth transition for users of the SDK and maintain consistency across all aspects of the project.
releases/sdks/go/docs/sdks/v1/README.md (1)
Line range hint
1-563: Consider adding a prominent notice about the authentication changeWhile the authentication change has been consistently applied across all examples, it would be beneficial to add a prominent notice at the beginning of the README file. This notice should highlight the breaking change in authentication method from
AuthorizationtoClientID.Consider adding the following notice at the beginning of the file:
# Important Notice **Breaking Change**: The authentication method has been updated from using `Authorization` to `ClientID`. Please ensure you update your environment variables and authentication setup accordingly. All examples in this document reflect this change.releases/sdks/go/docs/sdks/formanceorchestrationv1/README.md (1)
Line range hint
1-1: Consider adding a note about the security configuration change.While all examples have been correctly updated to use
ClientIDinstead ofAuthorization, it might be helpful for users to add a brief note at the beginning of the file explaining this change in the security configuration. This would provide context for the new pattern used throughout the examples.releases/sdks/go/v1.go (7)
697-697: OAuth2 scopes updated for GetOIDCWellKnowns method, but can be optimizedThe OAuth2Scopes for the GetOIDCWellKnowns method have been set to
{"auth:read", "auth:read"}. While this change is consistent with the read-only nature of the operation, the duplicate "auth:read" scope is redundant.Consider optimizing this to:
-OAuth2Scopes: []string{"auth:read", "auth:read"}, +OAuth2Scopes: []string{"auth:read"},
854-854: OAuth2 scopes updated for GetServerInfo method, but can be optimizedThe OAuth2Scopes for the GetServerInfo method have been set to
{"auth:read", "auth:read"}. While this change is consistent with the read-only nature of the operation, the duplicate "auth:read" scope is redundant.Consider optimizing this to:
-OAuth2Scopes: []string{"auth:read", "auth:read"}, +OAuth2Scopes: []string{"auth:read"},
1022-1022: OAuth2 scopes updated for ListClients method, but can be optimizedThe OAuth2Scopes for the ListClients method have been set to
{"auth:read", "auth:read"}. While this change is consistent with the read-only nature of the operation, the duplicate "auth:read" scope is redundant.Consider optimizing this to:
-OAuth2Scopes: []string{"auth:read", "auth:read"}, +OAuth2Scopes: []string{"auth:read"},
1191-1191: OAuth2 scopes updated for ListUsers method, but can be optimizedThe OAuth2Scopes for the ListUsers method have been set to
{"auth:read", "auth:read"}. While this change is consistent with the read-only nature of the operation, the duplicate "auth:read" scope is redundant.Consider optimizing this to:
-OAuth2Scopes: []string{"auth:read", "auth:read"}, +OAuth2Scopes: []string{"auth:read"},
1359-1359: OAuth2 scopes updated for ReadClient method, but can be optimizedThe OAuth2Scopes for the ReadClient method have been set to
{"auth:read", "auth:read"}. While this change is consistent with the read-only nature of the operation, the duplicate "auth:read" scope is redundant.Consider optimizing this to:
-OAuth2Scopes: []string{"auth:read", "auth:read"}, +OAuth2Scopes: []string{"auth:read"},
1528-1528: OAuth2 scopes updated for ReadUser method, but can be optimizedThe OAuth2Scopes for the ReadUser method have been set to
{"auth:read", "auth:read"}. While this change is consistent with the read-only nature of the operation, the duplicate "auth:read" scope is redundant.Consider optimizing this to:
-OAuth2Scopes: []string{"auth:read", "auth:read"}, +OAuth2Scopes: []string{"auth:read"},
Line range hint
1-1696: Overall assessment: OAuth2 scopes successfully implemented with minor optimization opportunityThe changes in this file consistently implement OAuth2 scopes across all methods of the
V1struct, which is a significant improvement to the SDK's security model. The scopes are generally appropriate for each method's functionality.However, there's a minor optimization opportunity:
- For methods that only require read access (GetOIDCWellKnowns, GetServerInfo, ListClients, ListUsers, ReadClient, ReadUser), the OAuth2Scopes are set to
{"auth:read", "auth:read"}. This duplicate scope is unnecessary.Consider applying the following optimization globally:
For all read-only methods:
-OAuth2Scopes: []string{"auth:read", "auth:read"}, +OAuth2Scopes: []string{"auth:read"},This change will maintain the intended functionality while slightly reducing the verbosity of the code.
releases/sdks/go/docs/sdks/formancev2/README.md (1)
Line range hint
1-1022: Consider enhancing documentation for clarityWhile the code examples have been consistently updated to use the new
CLIENT_IDauthentication method, the explanatory text surrounding these examples hasn't been modified to reflect this change.To improve user experience and reduce potential confusion:
- Add a section at the beginning of the README explaining the change in authentication method.
- Update the text preceding each code example to mention the use of
CLIENT_IDfor authentication.- If applicable, include information about why this change was made and any benefits it provides to users.
These additions will help users understand the new authentication process more clearly and adapt their implementations accordingly.
releases/sdks/go/.speakeasy/gen.lock (1)
Line range hint
10-28: New OAuth 2.0 Client Credentials feature addedA new feature
oauth2ClientCredentials(version 0.1.1) has been added to thegofeatures section. This indicates the implementation or update of the OAuth 2.0 client credentials flow in the SDK.Please ensure the following actions are taken:
- Update the SDK documentation to reflect this new authentication method.
- Provide usage examples for the OAuth 2.0 client credentials flow.
- If applicable, update any existing authentication-related code samples.
Consider adding a section in the README.md or USAGE.md file to explain how to use this new feature.
releases/sdks/go/formancev1.go (1)
3278-3278: OAuth2Scopes correctly implemented, but method is deprecatedThe addition of OAuth2Scopes with
{"auth:read", "ledger:write"}is appropriate for theRunScriptmethod. This ensures proper authorization for executing scripts that may modify the ledger. However, it's important to note that this method is marked as deprecated and will be removed in a future release.Consider adding a TODO comment to remind developers to remove this method in the future or to update client code to use the replacement method.
releases/sdks/go/docs/sdks/formancepaymentsv1/README.md (2)
71-72: LGTM! Consider adding error handling for missing environment variable.The change from
AuthorizationtoClientIDis consistent with the updated authentication mechanism. Using an environment variable for the client ID is a good security practice.Consider adding a check to ensure the
CLIENT_IDenvironment variable is set, and provide a meaningful error message if it's missing. For example:clientID := os.Getenv("CLIENT_ID") if clientID == "" { log.Fatal("CLIENT_ID environment variable is not set") }
Line range hint
1-2499: Overall LGTM! Consider global improvement for error handling.The changes in this file consistently update the security configuration across all examples, replacing
AuthorizationwithClientID. This systematic update reflects a change in the authentication mechanism for the entire SDK.Consider implementing a global helper function for setting up the security configuration with proper error handling. This could be added to the SDK itself and used in all examples. For instance:
func NewSecurityConfig() (shared.Security, error) { clientID := os.Getenv("CLIENT_ID") if clientID == "" { return shared.Security{}, errors.New("CLIENT_ID environment variable is not set") } return shared.Security{ ClientID: v2.String(clientID), }, nil }This would allow for centralized error handling and make the examples more concise and consistent.
releases/sdks/go/internal/hooks/clientcredentials.go (2)
213-213: Consider Using a Stronger Hash Function for Session KeysThe
getSessionKeyfunction uses MD5 to hash the client ID and client secret for session management. While MD5 is acceptable for non-cryptographic purposes, it's generally recommended to use a stronger hash function like SHA-256 to follow best security practices.Apply this diff to use SHA-256:
+import "crypto/sha256" func getSessionKey(clientID, clientSecret string) string { key := fmt.Sprintf("%s:%s", clientID, clientSecret) - hash := md5.Sum([]byte(key)) + hash := sha256.Sum256([]byte(key)) return hex.EncodeToString(hash[:]) }
253-255: Clarify Token Expiration LogicIn the
hasTokenExpiredfunction, you're checking if the token is expired by adding a 60-second buffer (time.Now().Unix() + 60 >= *expiresAt). Ensure that this buffer aligns with your token refresh policy. If intentional, consider adding a comment to explain the reasoning behind the 60-second buffer for better clarity.
Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Files ignored due to path filters (3)
releases/base.yamlis excluded by!**/*.yamlreleases/sdks/go/gen.yamlis excluded by!**/*.yamlreleases/templates/sdk/go/gen.yamlis excluded by!**/*.yaml
Files selected for processing (32)
- releases/sdks/go/.speakeasy/gen.lock (3 hunks)
- releases/sdks/go/README.md (11 hunks)
- releases/sdks/go/USAGE.md (1 hunks)
- releases/sdks/go/docs/pkg/models/shared/security.md (1 hunks)
- releases/sdks/go/docs/sdks/formance/README.md (1 hunks)
- releases/sdks/go/docs/sdks/formanceorchestrationv1/README.md (17 hunks)
- releases/sdks/go/docs/sdks/formancepaymentsv1/README.md (43 hunks)
- releases/sdks/go/docs/sdks/formancereconciliationv1/README.md (8 hunks)
- releases/sdks/go/docs/sdks/formancesearchv1/README.md (2 hunks)
- releases/sdks/go/docs/sdks/formancev1/README.md (20 hunks)
- releases/sdks/go/docs/sdks/formancev2/README.md (18 hunks)
- releases/sdks/go/docs/sdks/formancewalletsv1/README.md (16 hunks)
- releases/sdks/go/docs/sdks/formancewebhooksv1/README.md (7 hunks)
- releases/sdks/go/docs/sdks/v1/README.md (11 hunks)
- releases/sdks/go/docs/sdks/v2/README.md (26 hunks)
- releases/sdks/go/formance.go (2 hunks)
- releases/sdks/go/formanceorchestrationv1.go (17 hunks)
- releases/sdks/go/formancepaymentsv1.go (43 hunks)
- releases/sdks/go/formancereconciliationv1.go (8 hunks)
- releases/sdks/go/formancesearchv1.go (2 hunks)
- releases/sdks/go/formancev1.go (20 hunks)
- releases/sdks/go/formancev2.go (18 hunks)
- releases/sdks/go/formancewalletsv1.go (16 hunks)
- releases/sdks/go/formancewebhooksv1.go (7 hunks)
- releases/sdks/go/internal/hooks/clientcredentials.go (1 hunks)
- releases/sdks/go/internal/hooks/hooks.go (1 hunks)
- releases/sdks/go/internal/hooks/ledger.go (0 hunks)
- releases/sdks/go/internal/hooks/registration.go (0 hunks)
- releases/sdks/go/pkg/models/shared/security.go (1 hunks)
- releases/sdks/go/v1.go (11 hunks)
- releases/sdks/go/v2.go (26 hunks)
- tests/integration/temporalite.Dockerfile (2 hunks)
Files not reviewed due to no reviewable changes (2)
- releases/sdks/go/internal/hooks/ledger.go
- releases/sdks/go/internal/hooks/registration.go
Additional context used
Markdownlint
releases/sdks/go/README.md
4-4: null
Images should have alternate text (alt text)(MD045, no-alt-text)
46-46: Column: 1
Hard tabs(MD010, no-hard-tabs)
287-287: Column: 1
Hard tabs(MD010, no-hard-tabs)
288-288: Column: 1
Hard tabs(MD010, no-hard-tabs)
289-289: Column: 1
Hard tabs(MD010, no-hard-tabs)
290-290: Column: 1
Hard tabs(MD010, no-hard-tabs)
291-291: Column: 1
Hard tabs(MD010, no-hard-tabs)
292-292: Column: 1
Hard tabs(MD010, no-hard-tabs)
293-293: Column: 1
Hard tabs(MD010, no-hard-tabs)
297-297: Column: 1
Hard tabs(MD010, no-hard-tabs)
298-298: Column: 1
Hard tabs(MD010, no-hard-tabs)
299-299: Column: 1
Hard tabs(MD010, no-hard-tabs)
300-300: Column: 1
Hard tabs(MD010, no-hard-tabs)
301-301: Column: 1
Hard tabs(MD010, no-hard-tabs)
303-303: Column: 1
Hard tabs(MD010, no-hard-tabs)
304-304: Column: 1
Hard tabs(MD010, no-hard-tabs)
305-305: Column: 1
Hard tabs(MD010, no-hard-tabs)
306-306: Column: 1
Hard tabs(MD010, no-hard-tabs)
307-307: Column: 1
Hard tabs(MD010, no-hard-tabs)
308-308: Column: 1
Hard tabs(MD010, no-hard-tabs)
309-309: Column: 1
Hard tabs(MD010, no-hard-tabs)
310-310: Column: 1
Hard tabs(MD010, no-hard-tabs)
311-311: Column: 1
Hard tabs(MD010, no-hard-tabs)
312-312: Column: 1
Hard tabs(MD010, no-hard-tabs)
313-313: Column: 1
Hard tabs(MD010, no-hard-tabs)
314-314: Column: 1
Hard tabs(MD010, no-hard-tabs)
315-315: Column: 1
Hard tabs(MD010, no-hard-tabs)
316-316: Column: 1
Hard tabs(MD010, no-hard-tabs)
317-317: Column: 1
Hard tabs(MD010, no-hard-tabs)
318-318: Column: 1
Hard tabs(MD010, no-hard-tabs)
319-319: Column: 1
Hard tabs(MD010, no-hard-tabs)
320-320: Column: 1
Hard tabs(MD010, no-hard-tabs)
330-330: Column: 1
Hard tabs(MD010, no-hard-tabs)
331-331: Column: 1
Hard tabs(MD010, no-hard-tabs)
332-332: Column: 1
Hard tabs(MD010, no-hard-tabs)
333-333: Column: 1
Hard tabs(MD010, no-hard-tabs)
334-334: Column: 1
Hard tabs(MD010, no-hard-tabs)
335-335: Column: 1
Hard tabs(MD010, no-hard-tabs)
339-339: Column: 1
Hard tabs(MD010, no-hard-tabs)
340-340: Column: 1
Hard tabs(MD010, no-hard-tabs)
341-341: Column: 1
Hard tabs(MD010, no-hard-tabs)
342-342: Column: 1
Hard tabs(MD010, no-hard-tabs)
343-343: Column: 1
Hard tabs(MD010, no-hard-tabs)
344-344: Column: 1
Hard tabs(MD010, no-hard-tabs)
345-345: Column: 1
Hard tabs(MD010, no-hard-tabs)
346-346: Column: 1
Hard tabs(MD010, no-hard-tabs)
347-347: Column: 1
Hard tabs(MD010, no-hard-tabs)
348-348: Column: 1
Hard tabs(MD010, no-hard-tabs)
349-349: Column: 1
Hard tabs(MD010, no-hard-tabs)
350-350: Column: 1
Hard tabs(MD010, no-hard-tabs)
351-351: Column: 1
Hard tabs(MD010, no-hard-tabs)
352-352: Column: 1
Hard tabs(MD010, no-hard-tabs)
353-353: Column: 1
Hard tabs(MD010, no-hard-tabs)
354-354: Column: 1
Hard tabs(MD010, no-hard-tabs)
356-356: Column: 1
Hard tabs(MD010, no-hard-tabs)
357-357: Column: 1
Hard tabs(MD010, no-hard-tabs)
358-358: Column: 1
Hard tabs(MD010, no-hard-tabs)
359-359: Column: 1
Hard tabs(MD010, no-hard-tabs)
360-360: Column: 1
Hard tabs(MD010, no-hard-tabs)
361-361: Column: 1
Hard tabs(MD010, no-hard-tabs)
362-362: Column: 1
Hard tabs(MD010, no-hard-tabs)
363-363: Column: 1
Hard tabs(MD010, no-hard-tabs)
399-399: Column: 1
Hard tabs(MD010, no-hard-tabs)
468-468: Column: 1
Hard tabs(MD010, no-hard-tabs)
469-469: Column: 1
Hard tabs(MD010, no-hard-tabs)
470-470: Column: 1
Hard tabs(MD010, no-hard-tabs)
505-505: Column: 1
Hard tabs(MD010, no-hard-tabs)
578-578: Column: 1
Hard tabs(MD010, no-hard-tabs)
616-616: null
Bare URL used(MD034, no-bare-urls)
releases/sdks/go/USAGE.md
16-16: Column: 1
Hard tabs(MD010, no-hard-tabs)
LanguageTool
releases/sdks/go/README.md
[style] ~614-~614: The phrase ‘feel free to’ is used quite frequently. Consider using a less frequent alternative to set your writing apart from others and make it sound more professional.
Context: ... look forward to hearing your feedback. Feel free to open a PR or an issue with a proof of c...(FEEL_FREE_TO_STYLE_ME)
[uncategorized] ~614-~614: Use a comma before ‘and’ if it connects two independent clauses (unless they are closely connected and short).
Context: ...a PR or an issue with a proof of concept and we'll do our best to include it in a fu...(COMMA_COMPOUND_SENTENCE)
Additional comments not posted (173)
releases/sdks/go/docs/pkg/models/shared/security.md (3)
6-10: LGTM: Table structure and formattingThe overall structure and formatting of the table look good. The changes are consistent and maintain the existing style.
8-10: Verify the correct type for new fieldsThe type
**string*seems unusual and might be a typo. Typically, we would expect*stringfor a pointer to a string in Go.Please confirm if
**string*is the intended type or if it should be corrected to*string.#!/bin/bash # Search for other occurrences of **string* in markdown files rg --type md "\*\*string\*" ./releases/sdks
6-10: Verify the impact of removing theAuthorizationfieldThe
Authorizationfield has been removed and replaced withClientID,ClientSecret, andTokenURL. This change suggests a shift towards a more complex authentication mechanism, possibly OAuth.Please ensure that:
- This change is intentional and aligns with the API's authentication strategy.
- Existing implementations using the
Authorizationfield are updated accordingly.- Documentation elsewhere in the project reflects this change in authentication method.
Verification successful
The removal of the
Authorizationfield has been successfully verified.
- No references to
Authorizationwere found in the markdown documentation within./releases/sdks, confirming its removal.- The documentation now correctly includes the new fields:
ClientID,ClientSecret, andTokenURL.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Search for references to the old Authorization field rg --type md "Authorization.*\*string\*" ./releases/sdksLength of output: 167422
Script:
#!/bin/bash # Corrected: Search for references to the old Authorization field with properly escaped asterisks rg --type md 'Authorization.*\*\*string\*' ./releases/sdksLength of output: 60
tests/integration/temporalite.Dockerfile (2)
1-1: LGTM: Builder image change improves accessibilityThe change from
public.ecr.aws/docker/library/golang:1.19togolang:1.19is a good improvement. This uses the official Docker Hub image for Go 1.19, which:
- Simplifies the build process by removing the AWS ECR registry dependency.
- Potentially improves build reliability by eliminating possible ECR authentication issues.
- Maintains the same Go version (1.19), ensuring no unexpected changes in the build environment.
11-11: LGTM: Final image change aligns with builder image improvementChanging the base image from
public.ecr.aws/debian/debian:stable-slimtodebian:stable-slimis consistent with the builder image change and brings similar benefits:
- Simplifies the image pulling process by using the official Docker Hub Debian image.
- Removes the dependency on AWS ECR, potentially improving build reliability.
- Maintains the same Debian version ("stable-slim"), ensuring consistency in the runtime environment.
While there might be slight differences in underlying Debian packages between ECR and Docker Hub images, these are likely minimal and shouldn't affect the application's functionality.
releases/sdks/go/pkg/models/shared/security.go (4)
5-8: LGTM: Import statements are correct and necessary.The new imports for
typesandutilsfrom the SDK package are appropriate for the added functionality.
27-39: LGTM: Getter methods for ClientID and ClientSecret are well-implemented.The
GetClientIDandGetClientSecretmethods are correctly implemented with proper nil checks. They provide safe access to the struct fields and maintain consistency by returning pointers.
41-43: Consider revising the GetTokenURL method implementation.The
GetTokenURLmethod always returns the same constant value and doesn't use thetokenURLfield of the struct. This implementation might not be as expected.
- If the intention is to always return a constant value, consider making this a package-level constant instead of a method:
var TokenURL = types.String("/api/auth/oauth/token")
- If the method should return the value of the
tokenURLfield, modify it as follows:func (o *Security) GetTokenURL() *string { if o == nil { return nil } return o.tokenURL }Could you please clarify the intended behavior of this method? Should it return a constant value or the value of the
tokenURLfield?#!/bin/bash # Description: Check for other usages of GetTokenURL to understand the expected behavior rg --type go '\.GetTokenURL\(' -A 2 -B 2
16-18: LGTM: MarshalJSON method added correctly.The
MarshalJSONmethod is correctly implemented to satisfy thejson.Marshalerinterface.Could you please clarify the purpose of the empty string and
falsearguments in theutils.MarshalJSONcall? A comment explaining these might be helpful for future maintenance.Verification successful
MarshalJSON Implementation Verified
All instances of
utils.MarshalJSONacross the codebase consistently use the empty string andfalsearguments, ensuring standardized marshaling behavior.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Check for other usages of utils.MarshalJSON to understand the pattern rg --type go 'utils\.MarshalJSON\(' -A 2 -B 2Length of output: 434
Script:
#!/bin/bash # Description: Corrected search for usages of utils.MarshalJSON to understand the pattern rg --type go 'utils\.MarshalJSON\(' -A 2 -B 2Length of output: 85503
releases/sdks/go/docs/sdks/formance/README.md (1)
43-43: Authentication mechanism has changed from Authorization to ClientIDThe security configuration has been updated to use
ClientIDinstead ofAuthorization. This represents a significant change in the authentication flow for the SDK.
- Users will now need to provide a
CLIENT_IDenvironment variable instead of an authorization token.- This change aligns with a client identification mechanism rather than an authorization-based approach.
- The use of an environment variable for sensitive information is a good security practice.
To ensure this change is consistently applied and documented:
Consider updating the "Authentication" section at the beginning of this README to reflect this change in authentication mechanism. It currently mentions OAuth2 but doesn't specify the use of a Client ID.
releases/sdks/go/internal/hooks/hooks.go (1)
74-86: LGTM! Consider addingcctoafterSuccessHook.The changes look good. The addition of the
NewClientCredentialsHook()to various stages of the request lifecycle (init, before request, after error) enhances the SDK's capabilities for handling client credentials.However, I noticed that
ccis not added to theafterSuccessHookslice. Is there a specific reason for this omission? If not, consider adding it for consistency across all hook types.To ensure the
NewClientCredentialsHook()function exists and is implemented correctly, please run the following script:releases/sdks/go/docs/sdks/formancesearchv1/README.md (1)
94-94: LGTM! Consistent change across examples.The change from
AuthorizationtoClientIDin this example is consistent with the previous change, maintaining uniformity across the documentation.releases/sdks/go/formancesearchv1.go (3)
36-36: LGTM: Enhanced security with OAuth2 scopesThe addition of OAuth2 scopes ("auth:read" and "search:write") improves the security of the Search method by explicitly defining the required permissions. This change aligns well with the method's functionality and follows best practices for API security.
210-210: LGTM: Improved security with appropriate OAuth2 scopesThe addition of OAuth2 scopes ("auth:read" and "search:read") enhances the security of the SearchgetServerInfo method. These scopes accurately reflect the method's purpose of retrieving server information and maintain consistency with the authentication requirements across the API.
36-36: Summary: Successful implementation of OAuth2 scopesThe changes in this file successfully implement OAuth2 scopes for both the
SearchandSearchgetServerInfomethods. These additions enhance the API's security by clearly defining the required permissions for each operation. The scopes are consistent and appropriate for their respective methods:
Search: "auth:read" and "search:write"SearchgetServerInfo: "auth:read" and "search:read"These changes align well with the PR objectives and follow best practices for API security. Great job on improving the overall security posture of the Formance Search API!
Also applies to: 210-210
releases/sdks/go/formance.go (2)
26-27: LGTM: Addition of sandbox server URLThe inclusion of a sandbox server URL is a positive change. It provides developers with an environment for testing and development purposes, which is crucial for ensuring the reliability and correctness of integrations before moving to production.
220-220: LGTM: Addition of OAuth2 scope, but ensure documentation is updatedThe addition of the "auth:read" OAuth2 scope for the
GetVersionsfunction enhances security by following the principle of least privilege. This is a positive change.However, please ensure that this change is properly documented and communicated to users of the SDK, as it may require updates to existing integrations.
To verify if the documentation has been updated, please run the following command:
releases/sdks/go/docs/sdks/formancewebhooksv1/README.md (8)
35-35: Authentication method updatedThe change from
AuthorizationtoClientIDin the security configuration is correct and consistent with the new authentication approach. This update improves the clarity of the authentication process by using a more specific environment variable name.
94-94: Consistent authentication updateThe change from
AuthorizationtoClientIDis consistently applied here, maintaining uniformity across different examples in the README. This consistency helps prevent confusion for developers using the SDK.
152-152: Authentication update consistently appliedThe
ClientIDchange is correctly and consistently applied in this example as well.
207-207: Global authentication method updateThe consistent change to
ClientIDacross multiple examples indicates a global update to the authentication method. This systematic approach ensures that all parts of the documentation reflect the new authentication strategy.
262-262: Consistent authentication update maintainedThe
ClientIDchange is correctly applied here, maintaining consistency throughout the documentation.
326-326: Uniform authentication method across SDKThe consistent application of the
ClientIDchange in this example further reinforces the uniform update to the authentication method across the entire SDK. This consistency ensures that developers will have a clear and standardized approach to authentication regardless of which part of the SDK they are using.
387-387: Comprehensive authentication update completedThis final instance of the
ClientIDchange completes the comprehensive update to the authentication method across all examples in the README. The uniform application of this change enhances the clarity and consistency of the SDK documentation, providing a seamless experience for developers integrating with the Formance Webhooks V1 API.
Line range hint
1-413: Summary: Successful global update to authentication methodThe changes in this file represent a comprehensive and consistent update to the authentication method used in the Formance Webhooks V1 SDK. The replacement of
AuthorizationwithClientIDacross all code examples ensures that the documentation accurately reflects the new authentication approach. This uniform update enhances the clarity and usability of the SDK, providing developers with a consistent and clear method for authentication across all API interactions.Key points:
- All changes are consistently implemented across the entire README.
- The new authentication method using
ClientIDis clearly demonstrated in every relevant code example.- The uniformity of these changes minimizes the risk of confusion for developers using different parts of the SDK.
Overall, this update significantly improves the SDK's documentation and aligns it with the new authentication standards.
releases/sdks/go/docs/sdks/formancereconciliationv1/README.md (4)
95-95: Authentication change consistently appliedThe security configuration update from
AuthorizationtoClientIDhas been consistently applied in this example.The change is consistent with the previous example, maintaining uniformity across the README.
205-205: Authentication change consistently appliedThe security configuration update from
AuthorizationtoClientIDhas been consistently applied in this example as well.The change maintains consistency across all examples in the README.
316-316: Authentication change consistently appliedThe security configuration update from
AuthorizationtoClientIDhas been consistently applied in this example as well.The change maintains consistency across all examples in the README.
35-35: Authentication method changed from Authorization to ClientIDThe security configuration has been updated to use
ClientIDinstead ofAuthorization. This change affects all examples in the README and represents a significant shift in how authentication is handled.Please ensure that:
- This change is intentional and aligns with the overall authentication strategy.
- The documentation is updated to reflect this change, including any setup instructions for users.
- Existing users are notified about the need to update their environment variables from
AUTHORIZATIONtoCLIENT_ID.To verify the consistency of this change across the codebase, run the following command:
This will help ensure that the change has been applied consistently across all relevant files.
releases/sdks/go/docs/sdks/v1/README.md (2)
92-92: Consistent authentication change appliedThe ClientID authentication change has been consistently applied across all examples in this file.
146-146: Authentication change consistently applied across all examplesThe switch from
AuthorizationtoClientIDfor authentication has been uniformly applied across all code examples in this file. This consistency ensures that all parts of the SDK documentation reflect the new authentication method.Also applies to: 200-200, 254-254, 304-304, 354-354, 404-404, 455-455, 509-509, 563-563
releases/sdks/go/README.md (7)
Line range hint
46-57: Updated example usage with new security schemeThe example usage has been updated to use the new
ClientIDsecurity scheme instead of the previousAuthorizationscheme. This change reflects the updated authentication method for the SDK.Tools
Markdownlint
44-44: Column: 1
Hard tabs(MD010, no-hard-tabs)
45-45: Column: 1
Hard tabs(MD010, no-hard-tabs)
46-46: Column: 1
Hard tabs(MD010, no-hard-tabs)
47-47: Column: 1
Hard tabs(MD010, no-hard-tabs)
48-48: Column: 1
Hard tabs(MD010, no-hard-tabs)
277-367: New retries section addedA comprehensive section on retries has been added to the README. This section explains how to configure retry strategies for individual API calls and globally for the SDK. The explanations are clear, and the provided code examples demonstrate both approaches effectively.
Tools
Markdownlint
287-287: Column: 1
Hard tabs(MD010, no-hard-tabs)
288-288: Column: 1
Hard tabs(MD010, no-hard-tabs)
289-289: Column: 1
Hard tabs(MD010, no-hard-tabs)
290-290: Column: 1
Hard tabs(MD010, no-hard-tabs)
291-291: Column: 1
Hard tabs(MD010, no-hard-tabs)
292-292: Column: 1
Hard tabs(MD010, no-hard-tabs)
293-293: Column: 1
Hard tabs(MD010, no-hard-tabs)
297-297: Column: 1
Hard tabs(MD010, no-hard-tabs)
298-298: Column: 1
Hard tabs(MD010, no-hard-tabs)
299-299: Column: 1
Hard tabs(MD010, no-hard-tabs)
300-300: Column: 1
Hard tabs(MD010, no-hard-tabs)
301-301: Column: 1
Hard tabs(MD010, no-hard-tabs)
303-303: Column: 1
Hard tabs(MD010, no-hard-tabs)
304-304: Column: 1
Hard tabs(MD010, no-hard-tabs)
305-305: Column: 1
Hard tabs(MD010, no-hard-tabs)
306-306: Column: 1
Hard tabs(MD010, no-hard-tabs)
307-307: Column: 1
Hard tabs(MD010, no-hard-tabs)
308-308: Column: 1
Hard tabs(MD010, no-hard-tabs)
309-309: Column: 1
Hard tabs(MD010, no-hard-tabs)
310-310: Column: 1
Hard tabs(MD010, no-hard-tabs)
311-311: Column: 1
Hard tabs(MD010, no-hard-tabs)
312-312: Column: 1
Hard tabs(MD010, no-hard-tabs)
313-313: Column: 1
Hard tabs(MD010, no-hard-tabs)
314-314: Column: 1
Hard tabs(MD010, no-hard-tabs)
315-315: Column: 1
Hard tabs(MD010, no-hard-tabs)
316-316: Column: 1
Hard tabs(MD010, no-hard-tabs)
317-317: Column: 1
Hard tabs(MD010, no-hard-tabs)
318-318: Column: 1
Hard tabs(MD010, no-hard-tabs)
319-319: Column: 1
Hard tabs(MD010, no-hard-tabs)
320-320: Column: 1
Hard tabs(MD010, no-hard-tabs)
330-330: Column: 1
Hard tabs(MD010, no-hard-tabs)
331-331: Column: 1
Hard tabs(MD010, no-hard-tabs)
332-332: Column: 1
Hard tabs(MD010, no-hard-tabs)
333-333: Column: 1
Hard tabs(MD010, no-hard-tabs)
334-334: Column: 1
Hard tabs(MD010, no-hard-tabs)
335-335: Column: 1
Hard tabs(MD010, no-hard-tabs)
339-339: Column: 1
Hard tabs(MD010, no-hard-tabs)
340-340: Column: 1
Hard tabs(MD010, no-hard-tabs)
341-341: Column: 1
Hard tabs(MD010, no-hard-tabs)
342-342: Column: 1
Hard tabs(MD010, no-hard-tabs)
343-343: Column: 1
Hard tabs(MD010, no-hard-tabs)
344-344: Column: 1
Hard tabs(MD010, no-hard-tabs)
345-345: Column: 1
Hard tabs(MD010, no-hard-tabs)
346-346: Column: 1
Hard tabs(MD010, no-hard-tabs)
347-347: Column: 1
Hard tabs(MD010, no-hard-tabs)
348-348: Column: 1
Hard tabs(MD010, no-hard-tabs)
349-349: Column: 1
Hard tabs(MD010, no-hard-tabs)
350-350: Column: 1
Hard tabs(MD010, no-hard-tabs)
351-351: Column: 1
Hard tabs(MD010, no-hard-tabs)
352-352: Column: 1
Hard tabs(MD010, no-hard-tabs)
353-353: Column: 1
Hard tabs(MD010, no-hard-tabs)
354-354: Column: 1
Hard tabs(MD010, no-hard-tabs)
356-356: Column: 1
Hard tabs(MD010, no-hard-tabs)
357-357: Column: 1
Hard tabs(MD010, no-hard-tabs)
358-358: Column: 1
Hard tabs(MD010, no-hard-tabs)
359-359: Column: 1
Hard tabs(MD010, no-hard-tabs)
360-360: Column: 1
Hard tabs(MD010, no-hard-tabs)
361-361: Column: 1
Hard tabs(MD010, no-hard-tabs)
362-362: Column: 1
Hard tabs(MD010, no-hard-tabs)
363-363: Column: 1
Hard tabs(MD010, no-hard-tabs)
Line range hint
368-436: Updated error handling sectionThe error handling section has been updated to reflect the new
ClientIDsecurity scheme in the example code. The information provided is accurate and helpful for users implementing error handling in their applications.Tools
Markdownlint
397-397: Column: 1
Hard tabs(MD010, no-hard-tabs)
398-398: Column: 1
Hard tabs(MD010, no-hard-tabs)
399-399: Column: 1
Hard tabs(MD010, no-hard-tabs)
400-400: Column: 1
Hard tabs(MD010, no-hard-tabs)
401-401: Column: 1
Hard tabs(MD010, no-hard-tabs)
402-402: Column: 1
Hard tabs(MD010, no-hard-tabs)
Line range hint
437-522: Updated server selection sectionThe server selection section has been updated to use the new
ClientIDsecurity scheme in the example code. The instructions for selecting servers and overriding server URLs are clear and accurate.Tools
Markdownlint
467-467: Column: 1
Hard tabs(MD010, no-hard-tabs)
468-468: Column: 1
Hard tabs(MD010, no-hard-tabs)
469-469: Column: 1
Hard tabs(MD010, no-hard-tabs)
470-470: Column: 1
Hard tabs(MD010, no-hard-tabs)
471-471: Column: 1
Hard tabs(MD010, no-hard-tabs)
472-472: Column: 1
Hard tabs(MD010, no-hard-tabs)
Line range hint
555-593: Updated authentication sectionThe authentication section has been revised to include two security schemes:
ClientIDandClientSecret. The example code demonstrates how to use theClientIDscheme correctly. This update provides clear guidance on how to authenticate with the API using the new security schemes.
610-616: Updated development sectionThe development section has been updated to clarify that the SDK is in beta. It also includes important information about contributions, noting that manual changes to internal files will be overwritten on the next generation. This information is crucial for potential contributors and users of the SDK.
Tools
LanguageTool
[style] ~614-~614: The phrase ‘feel free to’ is used quite frequently. Consider using a less frequent alternative to set your writing apart from others and make it sound more professional.
Context: ... look forward to hearing your feedback. Feel free to open a PR or an issue with a proof of c...(FEEL_FREE_TO_STYLE_ME)
[uncategorized] ~614-~614: Use a comma before ‘and’ if it connects two independent clauses (unless they are closely connected and short).
Context: ...a PR or an issue with a proof of concept and we'll do our best to include it in a fu...(COMMA_COMPOUND_SENTENCE)
Markdownlint
616-616: null
Bare URL used(MD034, no-bare-urls)
Line range hint
1-616: Comprehensive update to the READMEThe README has been successfully updated with several important changes:
- Introduction of a new retries section, providing clear guidance on implementing retry strategies.
- Updated authentication method using
ClientIDandClientSecretsecurity schemes.- Consistent updates throughout the document to reflect the new security scheme in code examples.
- Clarification of the SDK's beta status and contribution guidelines.
These changes improve the overall quality and accuracy of the documentation, providing users with up-to-date information on how to use and contribute to the SDK.
Tools
Markdownlint
274-274: Expected: dash; Actual: asterisk
Unordered list style(MD004, ul-style)
287-287: Column: 1
Hard tabs(MD010, no-hard-tabs)
288-288: Column: 1
Hard tabs(MD010, no-hard-tabs)
289-289: Column: 1
Hard tabs(MD010, no-hard-tabs)
290-290: Column: 1
Hard tabs(MD010, no-hard-tabs)
291-291: Column: 1
Hard tabs(MD010, no-hard-tabs)
292-292: Column: 1
Hard tabs(MD010, no-hard-tabs)
293-293: Column: 1
Hard tabs(MD010, no-hard-tabs)
297-297: Column: 1
Hard tabs(MD010, no-hard-tabs)
298-298: Column: 1
Hard tabs(MD010, no-hard-tabs)
299-299: Column: 1
Hard tabs(MD010, no-hard-tabs)
300-300: Column: 1
Hard tabs(MD010, no-hard-tabs)
301-301: Column: 1
Hard tabs(MD010, no-hard-tabs)
303-303: Column: 1
Hard tabs(MD010, no-hard-tabs)
304-304: Column: 1
Hard tabs(MD010, no-hard-tabs)
305-305: Column: 1
Hard tabs(MD010, no-hard-tabs)
306-306: Column: 1
Hard tabs(MD010, no-hard-tabs)
307-307: Column: 1
Hard tabs(MD010, no-hard-tabs)
308-308: Column: 1
Hard tabs(MD010, no-hard-tabs)
309-309: Column: 1
Hard tabs(MD010, no-hard-tabs)
310-310: Column: 1
Hard tabs(MD010, no-hard-tabs)
311-311: Column: 1
Hard tabs(MD010, no-hard-tabs)
312-312: Column: 1
Hard tabs(MD010, no-hard-tabs)
313-313: Column: 1
Hard tabs(MD010, no-hard-tabs)
314-314: Column: 1
Hard tabs(MD010, no-hard-tabs)
315-315: Column: 1
Hard tabs(MD010, no-hard-tabs)
316-316: Column: 1
Hard tabs(MD010, no-hard-tabs)
317-317: Column: 1
Hard tabs(MD010, no-hard-tabs)
318-318: Column: 1
Hard tabs(MD010, no-hard-tabs)
319-319: Column: 1
Hard tabs(MD010, no-hard-tabs)
320-320: Column: 1
Hard tabs(MD010, no-hard-tabs)
330-330: Column: 1
Hard tabs(MD010, no-hard-tabs)
331-331: Column: 1
Hard tabs(MD010, no-hard-tabs)
332-332: Column: 1
Hard tabs(MD010, no-hard-tabs)
333-333: Column: 1
Hard tabs(MD010, no-hard-tabs)
334-334: Column: 1
Hard tabs(MD010, no-hard-tabs)
335-335: Column: 1
Hard tabs(MD010, no-hard-tabs)
339-339: Column: 1
Hard tabs(MD010, no-hard-tabs)
340-340: Column: 1
Hard tabs(MD010, no-hard-tabs)
341-341: Column: 1
Hard tabs(MD010, no-hard-tabs)
342-342: Column: 1
Hard tabs(MD010, no-hard-tabs)
343-343: Column: 1
Hard tabs(MD010, no-hard-tabs)
344-344: Column: 1
Hard tabs(MD010, no-hard-tabs)
345-345: Column: 1
Hard tabs(MD010, no-hard-tabs)
346-346: Column: 1
Hard tabs(MD010, no-hard-tabs)
347-347: Column: 1
Hard tabs(MD010, no-hard-tabs)
348-348: Column: 1
Hard tabs(MD010, no-hard-tabs)
349-349: Column: 1
Hard tabs(MD010, no-hard-tabs)
350-350: Column: 1
Hard tabs(MD010, no-hard-tabs)
351-351: Column: 1
Hard tabs(MD010, no-hard-tabs)
352-352: Column: 1
Hard tabs(MD010, no-hard-tabs)
353-353: Column: 1
Hard tabs(MD010, no-hard-tabs)
354-354: Column: 1
Hard tabs(MD010, no-hard-tabs)
356-356: Column: 1
Hard tabs(MD010, no-hard-tabs)
357-357: Column: 1
Hard tabs(MD010, no-hard-tabs)
358-358: Column: 1
Hard tabs(MD010, no-hard-tabs)
359-359: Column: 1
Hard tabs(MD010, no-hard-tabs)
360-360: Column: 1
Hard tabs(MD010, no-hard-tabs)
361-361: Column: 1
Hard tabs(MD010, no-hard-tabs)
362-362: Column: 1
Hard tabs(MD010, no-hard-tabs)
363-363: Column: 1
Hard tabs(MD010, no-hard-tabs)
releases/sdks/go/formancewebhooksv1.go (8)
36-36: LGTM: OAuth2Scopes correctly addedThe addition of OAuth2Scopes with "auth:read" and "webhooks:write" is appropriate for the ActivateConfig method. This change enhances security by specifying the required scopes for this operation.
218-218: LGTM: OAuth2Scopes correctly addedThe addition of OAuth2Scopes with "auth:read" and "webhooks:write" is appropriate for the ChangeConfigSecret method. This change ensures proper authorization for modifying sensitive information.
403-403: LGTM: OAuth2Scopes correctly addedThe addition of OAuth2Scopes with "auth:read" and "webhooks:write" is appropriate for the DeactivateConfig method. This change ensures proper authorization for deactivating webhook configurations.
582-582: LGTM: OAuth2Scopes correctly addedThe addition of OAuth2Scopes with "auth:read" and "webhooks:write" is appropriate for the DeleteConfig method. This change ensures proper authorization for deleting webhook configurations.
750-750: LGTM: OAuth2Scopes correctly added with appropriate read scopeThe addition of OAuth2Scopes with "auth:read" and "webhooks:read" is appropriate for the GetManyConfigs method. This change ensures proper authorization for retrieving webhook configurations. It's worth noting that this method correctly uses the "webhooks:read" scope instead of "webhooks:write", which is suitable for this read operation.
941-941: LGTM: OAuth2Scopes correctly addedThe addition of OAuth2Scopes with "auth:read" and "webhooks:write" is appropriate for the InsertConfig method. This change ensures proper authorization for creating new webhook configurations.
1126-1126: LGTM: OAuth2Scopes correctly added with appropriate read scopeThe addition of OAuth2Scopes with "auth:read" and "webhooks:read" is appropriate for the TestConfig method. This change ensures proper authorization for testing webhook configurations. It's worth noting that this method correctly uses the "webhooks:read" scope instead of "webhooks:write", which is suitable for this test operation that doesn't modify the configuration.
Line range hint
36-1126: Summary: Consistent and appropriate addition of OAuth2ScopesThe changes made to this file consistently add OAuth2Scopes to all methods of the FormanceWebhooksV1 struct. These additions enhance the security of the SDK by specifying the required scopes for each operation. The scopes are appropriately set:
- Write operations (ActivateConfig, ChangeConfigSecret, DeactivateConfig, DeleteConfig, InsertConfig) use "auth:read" and "webhooks:write".
- Read operations (GetManyConfigs, TestConfig) use "auth:read" and "webhooks:read".
This distinction ensures that each method has the minimum necessary permissions, adhering to the principle of least privilege. Overall, these changes significantly improve the security posture of the SDK.
releases/sdks/go/formancereconciliationv1.go (9)
36-36: OAuth2Scopes addition looks goodThe addition of OAuth2Scopes with "auth:read" and "reconciliation:write" is appropriate for the CreatePolicy method. This change enhances security by specifying the required permissions.
221-221: OAuth2Scopes addition is consistentThe OAuth2Scopes for DeletePolicy are correctly set to "auth:read" and "reconciliation:write". This is consistent with the CreatePolicy method and appropriate for a delete operation.
388-388: OAuth2Scopes correctly set for read operationThe OAuth2Scopes for GetPolicy are appropriately set to "auth:read" and "reconciliation:read". This correctly differentiates the read operation from write operations.
566-566: OAuth2Scopes consistent for read operationsThe OAuth2Scopes for GetReconciliation are correctly set to "auth:read" and "reconciliation:read", consistent with other read operations like GetPolicy.
744-744: OAuth2Scopes appropriate for list operationThe OAuth2Scopes for ListPolicies are correctly set to "auth:read" and "reconciliation:read". This is appropriate for a list operation, which is a type of read operation.
926-926: OAuth2Scopes consistent for list operationsThe OAuth2Scopes for ListReconciliations are correctly set to "auth:read" and "reconciliation:read", consistent with other list operations like ListPolicies.
1109-1109: OAuth2Scopes correctly set for write operationThe OAuth2Scopes for Reconcile are appropriately set to "auth:read" and "reconciliation:write". This correctly identifies the reconcile operation as a write operation.
1293-1293: OAuth2Scopes appropriate for server info retrievalThe OAuth2Scopes for ReconciliationgetServerInfo are correctly set to "auth:read" and "reconciliation:read". This is appropriate for retrieving server information, which is a read operation.
36-36: Overall OAuth2Scopes implementation is excellentThe addition of OAuth2Scopes to all methods in the FormanceReconciliationV1 struct is well-implemented and consistent. The scopes are appropriately set for each method:
- Write operations (CreatePolicy, DeletePolicy, Reconcile) use "auth:read" and "reconciliation:write".
- Read operations (GetPolicy, GetReconciliation, ListPolicies, ListReconciliations, ReconciliationgetServerInfo) use "auth:read" and "reconciliation:read".
This change enhances the security of the SDK by clearly specifying the required permissions for each operation. Great job on improving the API's security model!
Also applies to: 221-221, 388-388, 566-566, 744-744, 926-926, 1109-1109, 1293-1293
releases/sdks/go/docs/sdks/formancewalletsv1/README.md (4)
45-45: LGTM: Security configuration updated correctlyThe security configuration has been updated to use
CLIENT_IDinstead ofAUTHORIZATION, which is consistent with the new authentication method.
104-104: LGTM: Security configuration updated consistentlyThe security configuration has been updated to use
CLIENT_ID, maintaining consistency with the new authentication method across different operations.
159-159: LGTM: Consistent security configuration update across all examplesThe security configuration has been systematically updated in all code examples to use
CLIENT_IDinstead ofAUTHORIZATION. This change is consistent and correctly implements the new authentication method throughout the SDK documentation.Also applies to: 213-213, 286-286, 351-351, 407-407, 462-462, 520-520, 577-577, 632-632, 687-687, 741-741, 802-802, 857-857, 911-911
Line range hint
1-932: Summary: Authentication method updated consistently across SDK documentationThe changes in this file consistently update the authentication method from using an
AUTHORIZATIONenvironment variable to aCLIENT_IDenvironment variable. This modification has been applied uniformly across all code examples in the FormanceWalletsV1 SDK documentation.Key points:
- All examples now use
ClientID: v2.String(os.Getenv("CLIENT_ID"))for authentication.- The change is consistent and does not introduce any errors or inconsistencies.
- No other modifications were made to the code examples or documentation.
These changes effectively document the new authentication method for SDK users.
releases/sdks/go/docs/sdks/formanceorchestrationv1/README.md (3)
45-45: LGTM: Security configuration updated correctly.The
Authorizationfield has been correctly replaced withClientID, and the value is properly wrapped inv2.String(). This change is consistent with the new security configuration.
99-99: LGTM: Security configuration updated consistently.The
ClientIDfield has been correctly implemented, maintaining consistency with the new security configuration pattern.
154-154: LGTM: Consistent security configuration update across all examples.The
ClientIDfield has been correctly implemented in place ofAuthorizationacross all remaining examples. This change maintains consistency throughout the SDK documentation and aligns with the new security configuration pattern.Also applies to: 213-213, 268-268, 323-323, 378-378, 433-433, 489-489, 544-544, 600-600, 653-653, 707-707, 758-758, 810-810, 865-865, 920-920
releases/sdks/go/v1.go (5)
35-35: OAuth2 scopes correctly updated for CreateClient methodThe OAuth2Scopes for the CreateClient method have been appropriately set to
{"auth:read", "auth:write"}. This change aligns with the expected permissions for creating a client, which typically requires both read and write access.
209-209: OAuth2 scopes correctly updated for CreateSecret methodThe OAuth2Scopes for the CreateSecret method have been appropriately set to
{"auth:read", "auth:write"}. This change is consistent with the expected permissions for creating a secret, which typically requires both read and write access.
383-383: OAuth2 scopes correctly updated for DeleteClient methodThe OAuth2Scopes for the DeleteClient method have been appropriately set to
{"auth:read", "auth:write"}. This change aligns with the expected permissions for deleting a client, which typically requires both read and write access.
540-540: OAuth2 scopes correctly updated for DeleteSecret methodThe OAuth2Scopes for the DeleteSecret method have been appropriately set to
{"auth:read", "auth:write"}. This change is consistent with the expected permissions for deleting a secret, which typically requires both read and write access.
1696-1696: OAuth2 scopes correctly updated for UpdateClient methodThe OAuth2Scopes for the UpdateClient method have been appropriately set to
{"auth:read", "auth:write"}. This change aligns with the expected permissions for updating a client, which typically requires both read and write access.releases/sdks/go/docs/sdks/formancev2/README.md (1)
100-102: LGTM: Consistent authentication change across all examplesThe change from
AUTHORIZATIONtoCLIENT_IDin the security configuration is consistently applied across all code examples in the file. This ensures that the documentation is uniform and up-to-date with the new authentication method.Also applies to: 155-157, 214-216, 269-271, 324-326, 379-381, 434-436, 489-491, 541-543, 596-598, 654-656, 710-712, 767-769, 823-825, 878-880, 933-935, 988-990
releases/sdks/go/.speakeasy/gen.lock (3)
1-2: Version and ID changes look goodThe update to the
idfield is expected and doesn't require any specific action. ThelockVersionremains unchanged, which is correct.
Line range hint
29-1379: New file added for OAuth 2.0 Client CredentialsA new file
internal/hooks/clientcredentials.gohas been added to the list of generated files. This is consistent with the new OAuth 2.0 client credentials feature.Please take the following actions:
- Review the contents of
internal/hooks/clientcredentials.goto ensure it correctly implements the OAuth 2.0 client credentials flow.- Update any relevant documentation or guides to include information about this new file and its purpose.
- If there are any existing tests, consider adding new test cases to cover the functionality in this file.
You can use the following command to view the contents of the new file:
#!/bin/bash # View the contents of the new clientcredentials.go file cat internal/hooks/clientcredentials.go
3-9: Management section changes are appropriateThe updates to
docChecksumandconfigChecksumindicate changes in the documentation and configuration. This is expected when there are updates to the API or its documentation.Please verify that the documentation changes associated with the new
docChecksumare accurate and complete. You can run the following command to check for recent documentation changes:Verification successful
Management section changes are verified and appropriate
The updates to
docChecksumandconfigChecksumare accompanied by corresponding changes in the documentation files, ensuring consistency and accuracy in the SDK's configuration and documentation.Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Check for recent changes in documentation files git log -p --since="1 week ago" -- docs/Length of output: 109
Script:
#!/bin/bash # Search for documentation files in the repository fd --extension md --type f --hidden # Check for recent changes in all documentation files found git log -p --since="1 week ago" -- $(fd --extension md --type f --hidden)Length of output: 198216
releases/sdks/go/docs/sdks/formancev1/README.md (18)
49-49: LGTM: ClientID correctly replaces AuthorizationThe change from
AuthorizationtoClientIDis correct and consistent with the expected update.
120-120: LGTM: ClientID consistently usedThe change from
AuthorizationtoClientIDis consistent with the previous example and correctly implemented.
176-176: LGTM: ClientID consistently appliedThe change from
AuthorizationtoClientIDis consistently applied in this example as well.
235-235: LGTM: ClientID consistently used across examplesThe change from
AuthorizationtoClientIDis consistently applied in this example, maintaining uniformity across the SDK.
343-343: LGTM: ClientID consistently implementedThe change from
AuthorizationtoClientIDis consistently implemented in this example as well.
404-404: LGTM: ClientID consistently applied across all examplesThe change from
AuthorizationtoClientIDis consistently applied in this example, maintaining uniformity across all SDK examples.
484-484: LGTM: ClientID consistently used in GetAccount exampleThe change from
AuthorizationtoClientIDis consistently applied in the GetAccount example.
540-540: LGTM: ClientID consistently implemented in GetBalancesThe change from
AuthorizationtoClientIDis consistently implemented in the GetBalances example.
598-598: LGTM: ClientID consistently used in GetBalancesAggregatedThe change from
AuthorizationtoClientIDis consistently applied in the GetBalancesAggregated example.
653-653: LGTM: ClientID consistently implemented in GetInfoThe change from
AuthorizationtoClientIDis consistently implemented in the GetInfo example.
705-705: LGTM: ClientID consistently used in GetLedgerInfoThe change from
AuthorizationtoClientIDis consistently applied in the GetLedgerInfo example.
760-760: LGTM: ClientID consistently implemented in GetMappingThe change from
AuthorizationtoClientIDis consistently implemented in the GetMapping example.
816-816: LGTM: ClientID consistently used in GetTransactionThe change from
AuthorizationtoClientIDis consistently applied in the GetTransaction example.
872-872: LGTM: ClientID consistently implemented in ListAccountsThe change from
AuthorizationtoClientIDis consistently implemented in the ListAccounts example.
984-984: LGTM: ClientID consistently used in ListLogsThe change from
AuthorizationtoClientIDis consistently applied in the ListLogs example.
1042-1042: LGTM: ClientID consistently implemented in ListTransactionsThe change from
AuthorizationtoClientIDis consistently implemented in the ListTransactions example.
1105-1105: LGTM: ClientID consistently used in ReadStatsThe change from
AuthorizationtoClientIDis consistently applied in the ReadStats example.
Line range hint
1-1320: Overall changes look good: Consistent update from Authorization to ClientIDThe changes in this file are consistent and well-implemented across all 17 code examples. The replacement of
AuthorizationwithClientIDin the security configuration improves the SDK by using a more appropriate and specific authentication method. This update maintains the overall structure and logic of the examples while enhancing the security approach.Key points:
- All examples have been updated uniformly.
- No other changes were made to the code structure or logic.
- The change improves the clarity and specificity of the authentication method used.
These changes will provide a better developer experience and align the SDK more closely with best practices for authentication.
releases/sdks/go/formancewalletsv1.go (17)
35-35: OAuth2 scopes added appropriately.The
ConfirmHoldmethod now includes the OAuth2 scopes "auth:read" and "wallets:write". These scopes align well with the method's functionality of confirming a hold, which requires authentication and the ability to modify wallet data.
210-210: OAuth2 scopes added correctly.The
CreateBalancemethod now includes the OAuth2 scopes "auth:read" and "wallets:write". These scopes are appropriate for the method's functionality of creating a new balance, which requires authentication and the ability to modify wallet data.
396-396: OAuth2 scopes added appropriately.The
CreateWalletmethod now includes the OAuth2 scopes "auth:read" and "wallets:write". These scopes are well-suited for the method's functionality of creating a new wallet, which requires authentication and the ability to create new wallet data.
582-582: OAuth2 scopes added correctly.The
CreditWalletmethod now includes the OAuth2 scopes "auth:read" and "wallets:write". These scopes are appropriate for the method's functionality of crediting a wallet, which requires authentication and the ability to modify wallet data.
757-757: OAuth2 scopes added appropriately.The
DebitWalletmethod now includes the OAuth2 scopes "auth:read" and "wallets:write". These scopes align well with the method's functionality of debiting a wallet, which requires authentication and the ability to modify wallet data.
944-944: OAuth2 scopes added correctly.The
GetBalancemethod now includes the OAuth2 scopes "auth:read" and "wallets:read". These scopes are appropriate for the method's functionality of retrieving balance information, which requires authentication and read access to wallet data without modification.
1122-1122: OAuth2 scopes added appropriately.The
GetHoldmethod now includes the OAuth2 scopes "auth:read" and "wallets:read". These scopes align well with the method's functionality of retrieving hold information, which requires authentication and read access to wallet data without modification.
1300-1300: OAuth2 scopes added correctly.The
GetHoldsmethod now includes the OAuth2 scopes "auth:read" and "wallets:read". These scopes are appropriate for the method's functionality of retrieving all holds for a wallet, which requires authentication and read access to wallet data without modification.
1481-1481: OAuth2 scopes added appropriately.The
GetTransactionsmethod now includes the OAuth2 scopes "auth:read" and "wallets:read". These scopes align well with the method's functionality of retrieving transaction information, which requires authentication and read access to wallet data without modification.
1663-1663: OAuth2 scopes added correctly.The
GetWalletmethod now includes the OAuth2 scopes "auth:read" and "wallets:read". These scopes are appropriate for the method's functionality of retrieving wallet information, which requires authentication and read access to wallet data without modification.
1842-1842: OAuth2 scopes added appropriately.The
GetWalletSummarymethod now includes the OAuth2 scopes "auth:read" and "wallets:read". These scopes align well with the method's functionality of retrieving a wallet summary, which requires authentication and read access to wallet data without modification.
2021-2021: OAuth2 scopes added correctly.The
ListBalancesmethod now includes the OAuth2 scopes "auth:read" and "wallets:read". These scopes are appropriate for the method's functionality of listing balances of a wallet, which requires authentication and read access to wallet data without modification.
2189-2189: OAuth2 scopes added appropriately.The
ListWalletsmethod now includes the OAuth2 scopes "auth:read" and "wallets:read". These scopes align well with the method's functionality of listing all wallets, which requires authentication and read access to wallet data without modification.
2371-2371: OAuth2 scopes added correctly.The
UpdateWalletmethod now includes the OAuth2 scopes "auth:read" and "wallets:write". These scopes are appropriate for the method's functionality of updating a wallet, which requires authentication and the ability to modify wallet data.
2546-2546: OAuth2 scopes added appropriately.The
VoidHoldmethod now includes the OAuth2 scopes "auth:read" and "wallets:write". These scopes align well with the method's functionality of canceling a hold, which requires authentication and the ability to modify wallet data.
2715-2715: OAuth2 scopes added correctly.The
WalletsgetServerInfomethod now includes the OAuth2 scopes "auth:read" and "wallets:read". These scopes are appropriate for the method's functionality of retrieving server information, which requires authentication and read access to wallet-related data without modification.
Line range hint
1-2915: OAuth2 scopes consistently added to all methods.This update adds appropriate OAuth2 scopes to all methods in the
FormanceWalletsV1struct. The changes improve the SDK's security and access control by specifying the required permissions for each operation. The scopes are consistently applied:
- "auth:read" is used for authentication across all methods.
- "wallets:read" is used for methods that only retrieve data without modification.
- "wallets:write" is used for methods that modify wallet data.
These changes enhance the SDK's compliance with the principle of least privilege, ensuring that each method only requests the necessary permissions for its operation.
releases/sdks/go/docs/sdks/v2/README.md (2)
55-57: Security configuration updated to use ClientIDThe security configuration has been updated to use
ClientIDinstead ofAuthorization. This change is consistent across the entire file and represents a significant modification in how the SDK authenticates with the API. Using environment variables for sensitive information like the client ID is a good security practice.
115-117: Consistent update to ClientID in security configurationThis change is consistent with the previous update, replacing
AuthorizationwithClientIDin the security configuration. It's part of the global change in the authentication method across the SDK.releases/sdks/go/formanceorchestrationv1.go (18)
36-36: OAuth2Scopes addition looks goodThe addition of OAuth2Scopes with "auth:read" and "orchestration:write" is appropriate for the CancelEvent method, as it involves modifying the orchestration by canceling an event.
204-204: OAuth2Scopes addition is correctThe addition of OAuth2Scopes with "auth:read" and "orchestration:write" is appropriate for the CreateTrigger method, as it involves modifying the orchestration by creating a new trigger.
389-389: OAuth2Scopes addition is suitableThe addition of OAuth2Scopes with "auth:read" and "orchestration:write" is appropriate for the CreateWorkflow method, as it involves modifying the orchestration by creating a new workflow.
574-574: OAuth2Scopes addition is correctThe addition of OAuth2Scopes with "auth:read" and "orchestration:write" is appropriate for the DeleteTrigger method, as it involves modifying the orchestration by deleting a trigger.
742-742: OAuth2Scopes addition is suitableThe addition of OAuth2Scopes with "auth:read" and "orchestration:write" is appropriate for the DeleteWorkflow method, as it involves modifying the orchestration by deleting a workflow.
910-910: OAuth2Scopes addition is correctThe addition of OAuth2Scopes with "auth:read" and "orchestration:read" is appropriate for the GetInstance method, as it only involves reading information about a workflow instance.
1089-1089: OAuth2Scopes addition is suitableThe addition of OAuth2Scopes with "auth:read" and "orchestration:read" is appropriate for the GetInstanceHistory method, as it only involves reading the history of a workflow instance.
1268-1268: OAuth2Scopes addition is correctThe addition of OAuth2Scopes with "auth:read" and "orchestration:read" is appropriate for the GetInstanceStageHistory method, as it only involves reading the stage history of a workflow instance.
1447-1447: OAuth2Scopes addition is suitableThe addition of OAuth2Scopes with "auth:read" and "orchestration:read" is appropriate for the GetWorkflow method, as it only involves reading information about a workflow.
1626-1626: OAuth2Scopes addition is correctThe addition of OAuth2Scopes with "auth:read" and "orchestration:read" is appropriate for the ListInstances method, as it only involves reading a list of workflow instances.
1809-1809: OAuth2Scopes addition is suitableThe addition of OAuth2Scopes with "auth:read" and "orchestration:read" is appropriate for the ListTriggers method, as it only involves reading a list of triggers.
1992-1992: OAuth2Scopes addition is correctThe addition of OAuth2Scopes with "auth:read" and "orchestration:read" is appropriate for the ListTriggersOccurrences method, as it only involves reading a list of trigger occurrences.
2171-2171: OAuth2Scopes addition is suitableThe addition of OAuth2Scopes with "auth:read" and "orchestration:read" is appropriate for the ListWorkflows method, as it only involves reading a list of workflows.
2349-2349: OAuth2Scopes addition is correctThe addition of OAuth2Scopes with "auth:read" and "orchestration:read" is appropriate for the OrchestrationgetServerInfo method, as it only involves reading server information.
2528-2528: OAuth2Scopes addition is suitableThe addition of OAuth2Scopes with "auth:read" and "orchestration:read" is appropriate for the ReadTrigger method, as it only involves reading information about a trigger.
2707-2707: OAuth2Scopes addition is correctThe addition of OAuth2Scopes with "auth:read" and "orchestration:write" is appropriate for the RunWorkflow method, as it involves modifying the orchestration state by running a workflow.
2896-2896: OAuth2Scopes addition is suitableThe addition of OAuth2Scopes with "auth:read" and "orchestration:write" is appropriate for the SendEvent method, as it involves modifying the orchestration state by sending an event to a running workflow.
Line range hint
1-2999: Overall OAuth2Scopes implementation is correct and consistentThe changes made to this file consistently add appropriate OAuth2Scopes to all methods of the FormanceOrchestrationV1 struct. The scopes are correctly assigned based on whether the method is reading ("auth:read" and "orchestration:read") or modifying ("auth:read" and "orchestration:write") the orchestration. This implementation enhances the security of the SDK by ensuring that each method has the minimum required permissions.
releases/sdks/go/formancev2.go (19)
36-36: OAuth2 scopes correctly addedThe addition of OAuth2 scopes "auth:read" and "orchestration:write" is appropriate for the
CancelEventmethod, as it requires read access for authentication and write access for orchestration operations.
204-204: OAuth2 scopes correctly addedThe addition of OAuth2 scopes "auth:read" and "orchestration:write" is appropriate for the
CreateTriggermethod, as it requires read access for authentication and write access for creating a new trigger in the orchestration system.
389-389: OAuth2 scopes correctly addedThe addition of OAuth2 scopes "auth:read" and "orchestration:write" is appropriate for the
CreateWorkflowmethod, as it requires read access for authentication and write access for creating a new workflow in the orchestration system.
574-574: OAuth2 scopes correctly addedThe addition of OAuth2 scopes "auth:read" and "orchestration:write" is appropriate for the
DeleteTriggermethod, as it requires read access for authentication and write access for deleting a trigger from the orchestration system.
742-742: OAuth2 scopes correctly addedThe addition of OAuth2 scopes "auth:read" and "orchestration:write" is appropriate for the
DeleteWorkflowmethod, as it requires read access for authentication and write access for deleting a workflow from the orchestration system.
910-910: OAuth2 scopes correctly addedThe addition of OAuth2 scopes "auth:read" and "orchestration:read" is appropriate for the
GetInstancemethod, as it requires read access for both authentication and retrieving a workflow instance from the orchestration system.
1089-1089: OAuth2 scopes correctly addedThe addition of OAuth2 scopes "auth:read" and "orchestration:read" is appropriate for the
GetInstanceHistorymethod, as it requires read access for both authentication and retrieving the history of a workflow instance from the orchestration system.
1268-1268: OAuth2 scopes correctly addedThe addition of OAuth2 scopes "auth:read" and "orchestration:read" is appropriate for the
GetInstanceStageHistorymethod, as it requires read access for both authentication and retrieving the stage history of a workflow instance from the orchestration system.
1446-1446: OAuth2 scopes correctly addedThe addition of OAuth2 scopes "auth:read" and "orchestration:read" is appropriate for the
GetServerInfomethod, as it requires read access for both authentication and retrieving server information from the orchestration system.
1625-1625: OAuth2 scopes correctly addedThe addition of OAuth2 scopes "auth:read" and "orchestration:read" is appropriate for the
GetWorkflowmethod, as it requires read access for both authentication and retrieving a workflow from the orchestration system.
1804-1804: OAuth2 scopes correctly addedThe addition of OAuth2 scopes "auth:read" and "orchestration:read" is appropriate for the
ListInstancesmethod, as it requires read access for both authentication and listing workflow instances from the orchestration system.
1987-1987: OAuth2 scopes correctly addedThe addition of OAuth2 scopes "auth:read" and "orchestration:read" is appropriate for the
ListTriggersmethod, as it requires read access for both authentication and listing triggers from the orchestration system.
2170-2170: OAuth2 scopes correctly addedThe addition of OAuth2 scopes "auth:read" and "orchestration:read" is appropriate for the
ListTriggersOccurrencesmethod, as it requires read access for both authentication and listing trigger occurrences from the orchestration system.
2353-2353: OAuth2 scopes correctly addedThe addition of OAuth2 scopes "auth:read" and "orchestration:read" is appropriate for the
ListWorkflowsmethod, as it requires read access for both authentication and listing workflows from the orchestration system.
2536-2536: OAuth2 scopes correctly addedThe addition of OAuth2 scopes "auth:read" and "orchestration:read" is appropriate for the
ReadTriggermethod, as it requires read access for both authentication and reading a trigger from the orchestration system.
2715-2715: OAuth2 scopes correctly addedThe addition of OAuth2 scopes "auth:read" and "orchestration:write" is appropriate for the
RunWorkflowmethod, as it requires read access for authentication and write access for running a workflow in the orchestration system.
2904-2904: OAuth2 scopes correctly addedThe addition of OAuth2 scopes "auth:read" and "orchestration:write" is appropriate for the
SendEventmethod, as it requires read access for authentication and write access for sending an event to a running workflow in the orchestration system.
3078-3078: OAuth2 scopes correctly addedThe addition of OAuth2 scopes "auth:read" and "orchestration:write" is appropriate for the
TestTriggermethod, as it requires read access for authentication and write access for testing a trigger in the orchestration system.
Line range hint
1-3078: Summary: OAuth2 scopes successfully implemented across all methodsThis update consistently adds appropriate OAuth2 scopes to all methods in the
FormanceV2struct. The changes enhance the security model by enforcing specific scopes for various operations:
- Read operations use "auth:read" and "orchestration:read" scopes.
- Write operations use "auth:read" and "orchestration:write" scopes.
These additions improve access control and align with best practices for API security. The implementation is consistent and correct across all methods.
releases/sdks/go/formancev1.go (20)
35-35: OAuth2Scopes correctly implementedThe addition of OAuth2Scopes with
{"auth:read", "ledger:write"}is appropriate for theCreateTransactionsmethod. This ensures proper authorization for creating transactions in the ledger.
219-219: OAuth2Scopes correctly implementedThe addition of OAuth2Scopes with
{"auth:read", "ledger:write"}is appropriate for theAddMetadataOnTransactionmethod. This ensures proper authorization for adding metadata to transactions in the ledger.
392-392: OAuth2Scopes correctly implementedThe addition of OAuth2Scopes with
{"auth:read", "ledger:write"}is appropriate for theAddMetadataToAccountmethod. This ensures proper authorization for adding metadata to accounts in the ledger.
565-565: OAuth2Scopes correctly implementedThe addition of OAuth2Scopes with
{"auth:read", "ledger:read"}is appropriate for theCountAccountsmethod. This ensures proper authorization for reading account information from the ledger.
738-738: OAuth2Scopes correctly implementedThe addition of OAuth2Scopes with
{"auth:read", "ledger:read"}is appropriate for theCountTransactionsmethod. This ensures proper authorization for reading transaction information from the ledger.
911-911: OAuth2Scopes correctly implementedThe addition of OAuth2Scopes with
{"auth:read", "ledger:write"}is appropriate for theCreateTransactionmethod. This ensures proper authorization for creating a transaction in the ledger.
1099-1099: OAuth2Scopes correctly implementedThe addition of OAuth2Scopes with
{"auth:read", "ledger:read"}is appropriate for theGetAccountmethod. This ensures proper authorization for retrieving account information from the ledger.
1277-1277: OAuth2Scopes correctly implementedThe addition of OAuth2Scopes with
{"auth:read", "ledger:read"}is appropriate for theGetBalancesmethod. This ensures proper authorization for retrieving balance information from the ledger.
1459-1459: OAuth2Scopes correctly implementedThe addition of OAuth2Scopes with
{"auth:read", "ledger:read"}is appropriate for theGetBalancesAggregatedmethod. This ensures proper authorization for retrieving aggregated balance information from the ledger.
1641-1641: OAuth2Scopes correctly implementedThe addition of OAuth2Scopes with
{"auth:read", "ledger:read"}is appropriate for theGetInfomethod. This ensures proper authorization for retrieving server information.
1819-1819: OAuth2Scopes correctly implementedThe addition of OAuth2Scopes with
{"auth:read", "ledger:read"}is appropriate for theGetLedgerInfomethod. This ensures proper authorization for retrieving ledger information.
1997-1997: OAuth2Scopes correctly implementedThe addition of OAuth2Scopes with
{"auth:read", "ledger:read"}is appropriate for theGetMappingmethod. This ensures proper authorization for retrieving mapping information from the ledger.
2175-2175: OAuth2Scopes correctly implementedThe addition of OAuth2Scopes with
{"auth:read", "ledger:read"}is appropriate for theGetTransactionmethod. This ensures proper authorization for retrieving transaction information from the ledger.
2354-2354: OAuth2Scopes correctly implementedThe addition of OAuth2Scopes with
{"auth:read", "ledger:read"}is appropriate for theListAccountsmethod. This ensures proper authorization for listing accounts from the ledger.
2549-2549: OAuth2Scopes correctly implementedThe addition of OAuth2Scopes with
{"auth:read", "ledger:read"}is appropriate for theListLogsmethod. This ensures proper authorization for listing logs from the ledger.
2732-2732: OAuth2Scopes correctly implementedThe addition of OAuth2Scopes with
{"auth:read", "ledger:read"}is appropriate for theListTransactionsmethod. This ensures proper authorization for listing transactions from the ledger.
2915-2915: OAuth2Scopes correctly implementedThe addition of OAuth2Scopes with
{"auth:read", "ledger:read"}is appropriate for theReadStatsmethod. This ensures proper authorization for reading statistics from the ledger.
3093-3093: OAuth2Scopes correctly implementedThe addition of OAuth2Scopes with
{"auth:read", "ledger:write"}is appropriate for theRevertTransactionmethod. This ensures proper authorization for reverting transactions in the ledger.
3456-3456: OAuth2Scopes correctly implementedThe addition of OAuth2Scopes with
{"auth:read", "ledger:write"}is appropriate for theUpdateMappingmethod. This ensures proper authorization for updating the mapping in the ledger.
Line range hint
1-3639: Overall assessment: OAuth2Scopes successfully implementedThe review of
releases/sdks/go/formancev1.goshows that OAuth2Scopes have been correctly and consistently implemented across all methods of theFormanceV1struct. The scopes are appropriately set based on the nature of each operation (read or write) on the ledger. This implementation enhances the security model by ensuring that each method requires the proper authorization scopes.Key points:
- Read-only operations use
{"auth:read", "ledger:read"}scopes.- Write operations use
{"auth:read", "ledger:write"}scopes.- The changes are consistent across all methods.
- The
RunScriptmethod is correctly implemented but marked as deprecated.These changes improve the overall security and access control of the SDK. Great job on the implementation!
releases/sdks/go/v2.go (5)
35-35: OAuth2Scopes correctly addedThe addition of OAuth2Scopes
{"auth:read", "ledger:write"}to theAddMetadataOnTransactionmethod is appropriate and consistent with the expected changes.
214-214: OAuth2Scopes correctly addedThe addition of OAuth2Scopes
{"auth:read", "ledger:write"}to theAddMetadataToAccountmethod is appropriate and consistent with the expected changes.
393-393: OAuth2Scopes correctly added with appropriate permissionsThe addition of OAuth2Scopes
{"auth:read", "ledger:read"}to theCountAccountsmethod is appropriate. The use of "ledger:read" instead of "ledger:write" correctly reflects the read-only nature of this operation.
Line range hint
572-4528: OAuth2Scopes consistently and correctly applied to all methodsThe OAuth2Scopes have been appropriately added to all remaining methods in the file. The pattern of using
{"auth:read", "ledger:read"}for read operations and{"auth:read", "ledger:write"}for write operations is consistently applied throughout. This demonstrates a thoughtful and correct implementation of the scopes based on the nature of each operation.
Line range hint
1-4704: Overall assessment: Changes successfully implementedThe addition of OAuth2Scopes to all methods in this file has been implemented correctly and consistently. The scopes are appropriately set based on whether the operation involves reading or writing to the ledger. This change enhances the security and access control of the API. No other significant changes or issues were observed in the file.
releases/sdks/go/docs/sdks/formancepaymentsv1/README.md (2)
130-131: LGTM! Consistent with previous change.This update to the security configuration is consistent with the change in the previous example.
Please refer to the previous comment regarding error handling for the
CLIENT_IDenvironment variable.
191-192: LGTM! Consistent security configuration updates across all examples.All remaining changes in this file follow the same pattern of updating the security configuration to use
ClientIDinstead ofAuthorization. This consistent approach ensures that all examples in the documentation reflect the new authentication mechanism.The suggestion for error handling of the
CLIENT_IDenvironment variable, as mentioned in the first comment, applies to all these instances as well.Also applies to: 248-249, 306-307, 367-368, 426-427, 489-490, 544-545, 599-600, 657-658, 718-719, 775-776, 831-832, 888-889, 943-944, 999-1000, 1055-1056, 1110-1111, 1171-1172, 1223-1224, 1282-1283, 1336-1337, 1393-1394, 1451-1452, 1511-1512, 1571-1572, 1631-1632, 1685-1686, 1737-1738, 1799-1800, 1854-1855, 1910-1911, 1970-1971, 2027-2028, 2083-2084, 2139-2140, 2203-2204, 2263-2264, 2318-2319, 2374-2375, 2434-2435, 2498-2499
releases/sdks/go/formancepaymentsv1.go (1)
Line range hint
1-7528: OAuth2Scopes consistently added to all methodsThe changes in this file involve adding OAuth2Scopes to the HookContext for each method in the FormancePaymentsV1 struct. This addition is consistent across all methods and appears to be correctly implemented. The scopes are appropriately set based on the nature of each operation (read or write).
| @@ -13,7 +13,7 @@ import ( | |||
| func main() { | |||
| s := v2.New( | |||
| v2.WithSecurity(shared.Security{ | |||
| Authorization: os.Getenv("AUTHORIZATION"), | |||
| ClientID: v2.String(os.Getenv("CLIENT_ID")), | |||
There was a problem hiding this comment.
Tip
Codebase Verification
Remaining References to "Authorization" Found
Multiple references to "authorization" still exist in the codebase, which may affect the effectiveness of the change from Authorization to ClientID. Please review and address the following instances to ensure consistency and prevent potential integration issues:
tests/integration/suite/orchestration-triggers.goreleases/sdks/go/formance.goreleases/sdks/go/docs/sdks/formance/README.mdreleases/sdks/go/internal/hooks/clientcredentials.goreleases/sdks/go/pkg/utils/security.goreleases/sdks/go/pkg/models/shared/bankingcircleconfig.golibs/go-libs/oauth2/oauth2introspect/middleware.golibs/go-libs/auth/auth.goee/stargate/internal/client/interceptors/auth_interceptor.goee/gateway/internal/audit/messages/audit.gocomponents/ledger/pkg/client/internal/utils/security.goee/auth/pkg/oidc/client.goee/auth/pkg/oidc/storage.goee/auth/pkg/oidc/provider.goee/auth/pkg/oidc/grant_type_bearer.goee/auth/pkg/api/module.goee/auth/pkg/api/authorization/accesstoken.goee/auth/pkg/api/authorization/main_test.goee/auth/pkg/api/authorization/middleware.gocomponents/payments/cmd/connectors/internal/connectors/wise/client/client.gocomponents/payments/cmd/connectors/internal/connectors/stripe/translate.gocomponents/payments/cmd/connectors/internal/connectors/generic/client/client.gocomponents/fctl/pkg/clients.gocomponents/payments/cmd/connectors/internal/connectors/moneycorp/client/auth.gocomponents/payments/cmd/connectors/internal/connectors/modulr/hmac/hmac_test.gocomponents/payments/cmd/connectors/internal/connectors/modulr/hmac/hmac.gocomponents/payments/cmd/connectors/internal/connectors/bankingcircle/task_resolve.gocomponents/payments/cmd/connectors/internal/connectors/bankingcircle/errors.gocomponents/payments/cmd/connectors/internal/connectors/bankingcircle/config.gocomponents/payments/cmd/connectors/internal/connectors/bankingcircle/client/client.gocomponents/payments/cmd/connectors/internal/connectors/bankingcircle/client/transfer_payouts.gocomponents/payments/cmd/connectors/internal/connectors/bankingcircle/client/payments.gocomponents/payments/cmd/connectors/internal/connectors/bankingcircle/client/auth.gocomponents/payments/cmd/connectors/internal/connectors/bankingcircle/client/accounts.gocomponents/payments/cmd/connectors/internal/connectors/modulr/client/client.gocomponents/fctl/membershipclient/docs/DefaultApi.mdcomponents/fctl/membershipclient/README.mdcomponents/fctl/cmd/payments/connectors/views/banking_circle.gocomponents/fctl/cmd/login/controller.go
Please ensure that these references are updated appropriately or remain unchanged if they serve different purposes. This will help maintain consistency across the codebase and prevent potential issues with existing integrations.
Analysis chain
LGTM! Consider updating related documentation.
The change from Authorization to ClientID is implemented correctly and aligns with the new client identification-based approach.
However, this change might impact existing integrations that rely on the AUTHORIZATION environment variable. Please ensure that:
- All related documentation is updated to reflect this change.
- Users are informed about the need to update their environment variables from
AUTHORIZATIONtoCLIENT_ID.
Run the following script to check for any remaining references to the old AUTHORIZATION environment variable:
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for references to the old AUTHORIZATION environment variable
# Test: Search for AUTHORIZATION in markdown and Go files
rg --type md --type go 'AUTHORIZATION'
Length of output: 38
Script:
#!/bin/bash
# Description: Case-insensitive search for any references to "authorization" in the codebase
# Test: Search for "authorization" in all markdown and Go files, ignoring case
rg --ignore-case 'authorization' --type md --type go
Length of output: 14631
Tools
Markdownlint
16-16: Column: 1
Hard tabs(MD010, no-hard-tabs)
| @@ -147,7 +147,7 @@ import( | |||
| func main() { | |||
| s := v2.New( | |||
| v2.WithSecurity(shared.Security{ | |||
| Authorization: os.Getenv("AUTHORIZATION"), | |||
| ClientID: v2.String(os.Getenv("CLIENT_ID")), | |||
There was a problem hiding this comment.
Authentication change consistently applied with potential for improvement
The security configuration update from Authorization to ClientID has been consistently applied in this example as well.
The change maintains consistency across all examples in the README.
Consider extracting the security configuration into a separate code snippet that can be referenced in all examples. This would reduce duplication and make future updates easier. For example:
securityConfig := shared.Security{
ClientID: v2.String(os.Getenv("CLIENT_ID")),
}
s := v2.New(
v2.WithSecurity(securityConfig),
)This snippet could then be included at the beginning of the README and referenced in all examples, reducing repetition and improving maintainability.
| @@ -257,7 +257,7 @@ | |||
| func main() { | |||
| s := v2.New( | |||
| v2.WithSecurity(shared.Security{ | |||
| Authorization: os.Getenv("AUTHORIZATION"), | |||
| ClientID: v2.String(os.Getenv("CLIENT_ID")), | |||
There was a problem hiding this comment.
Authentication change consistently applied
The security configuration update from Authorization to ClientID has been consistently applied in this example as well.
The change maintains consistency across all examples in the README.
As suggested earlier, consider centralizing the security configuration to reduce repetition and improve maintainability.
| @@ -35,7 +35,7 @@ import( | |||
| func main() { | |||
| s := v2.New( | |||
| v2.WithSecurity(shared.Security{ | |||
| Authorization: os.Getenv("AUTHORIZATION"), | |||
| ClientID: v2.String(os.Getenv("CLIENT_ID")), | |||
There was a problem hiding this comment.
Authentication method changed from Authorization to ClientID
The SDK now uses ClientID instead of Authorization for authentication. This is a breaking change that affects all API calls. Ensure that your environment is updated to use the CLIENT_ID environment variable instead of AUTHORIZATION.
Update your environment configuration:
- export AUTHORIZATION=your_auth_token
+ export CLIENT_ID=your_client_idCommittable suggestion was skipped due to low confidence.
| ClientID: v2.String(os.Getenv("CLIENT_ID")), | ||
| }), | ||
| ) |
There was a problem hiding this comment.
Authentication method changed: Update documentation for users
The authentication method has been changed from using an AUTHORIZATION token to a CLIENT_ID. This change is consistent across all examples in the file.
Consider adding a note at the beginning of the README to inform users about this change in authentication method. Include information on how to migrate from the old method to the new one, and whether there's any backward compatibility support.
| ClientID: v2.String(os.Getenv("CLIENT_ID")), | ||
| }), | ||
| ) |
There was a problem hiding this comment.
Tip
Codebase Verification
Discrepancy Found in ClientID Occurrences
The verification revealed that there are only 25 instances of ClientID in Go files, whereas 32 were expected. This inconsistency indicates that some instances may not have been updated correctly.
Next Steps:
- Review
clientid_occurrences.txtto identify the specific locations ofClientIDand determine any missed updates. - Ensure all instances of
Authorizationhave been properly replaced withClientIDacross the codebase. - Check for variations in the usage of
ClientIDthat might have been overlooked during the initial replacement.
Analysis chain
Comprehensive update of authentication method across the SDK
The change from Authorization to ClientID has been consistently applied across all 32 instances in this file. This represents a significant and systematic update to the authentication method used by the SDK. Key points:
- The change is uniform and consistent throughout the file.
- It affects all example usages of the SDK, ensuring comprehensive documentation.
- The use of
os.Getenv("CLIENT_ID")is maintained, keeping the good practice of using environment variables for sensitive information.
This update likely reflects a change in the API's authentication requirements and ensures that all SDK users are informed about the new method.
To ensure this change has been applied consistently across the entire codebase, we can run the following check:
Also applies to: 230-232, 285-287, 347-349, 408-410, 491-493, 548-550, 605-607, 662-664, 716-718, 772-774, 826-828, 878-880, 933-935, 989-991, 1045-1047, 1101-1103, 1156-1158, 1213-1215, 1269-1271, 1326-1328, 1384-1386, 1440-1442, 1496-1498
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any remaining instances of Authorization in Go files
if rg --type go 'Authorization:' --glob '!releases/sdks/go/docs/sdks/v2/README.md'; then
echo "Found remaining instances of Authorization in Go files"
exit 1
else
echo "No remaining instances of Authorization found in Go files"
fi
# Check for consistent use of ClientID in Go files
if ! rg --type go 'ClientID:' | wc -l | grep -q '^32$'; then
echo "Inconsistent number of ClientID occurrences found"
exit 1
else
echo "Found expected 32 occurrences of ClientID"
fi
Length of output: 372
Script:
#!/bin/bash
# Count total number of ClientID occurrences in Go files
CLIENT_ID_COUNT=$(rg --type go 'ClientID:' | wc -l)
echo "Total ClientID occurrences: $CLIENT_ID_COUNT"
# List all files and line numbers where ClientID appears
rg --type go -n 'ClientID:' > clientid_occurrences.txt
echo "List of all ClientID occurrences has been saved to clientid_occurrences.txt"
Length of output: 315
| body, _ := io.ReadAll(res.Body) | ||
| return nil, fmt.Errorf("unexpected status code: %d: %s", res.StatusCode, body) | ||
| } |
There was a problem hiding this comment.
Caution: Response Body May Contain Sensitive Information
When handling non-2xx responses in doTokenRequest, the error message includes the response body. Be cautious as the response body may contain sensitive information. Consider limiting the information included in the error message to prevent potential leakage of sensitive data.
You might modify the error handling as follows:
if res.StatusCode < 200 || res.StatusCode >= 300 {
- body, _ := io.ReadAll(res.Body)
- return nil, fmt.Errorf("unexpected status code: %d: %s", res.StatusCode, body)
+ return nil, fmt.Errorf("unexpected status code: %d", res.StatusCode)
}Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| body, _ := io.ReadAll(res.Body) | |
| return nil, fmt.Errorf("unexpected status code: %d: %s", res.StatusCode, body) | |
| } | |
| return nil, fmt.Errorf("unexpected status code: %d", res.StatusCode) | |
| } |
| type clientCredentialsHook struct { | ||
| baseURL string | ||
| client HTTPClient | ||
| sessions map[string]*session |
There was a problem hiding this comment.
Potential Data Race in Session Management
The sessions map in clientCredentialsHook is accessed and modified without synchronization. Since instances of clientCredentialsHook could be used concurrently across multiple goroutines, this may lead to data races. Consider adding a mutex to synchronize access to the sessions map.
Apply this diff to add synchronization:
+import "sync"
type clientCredentialsHook struct {
baseURL string
client HTTPClient
+ mu sync.RWMutex
sessions map[string]*session
}Then, update access to sessions with the mutex:
In BeforeRequest:
func (c *clientCredentialsHook) BeforeRequest(ctx BeforeRequestContext, req *http.Request) (*http.Request, error) {
// ...
+ c.mu.RLock()
sess, ok := c.sessions[sessionKey]
+ c.mu.RUnlock()
// ...
if !ok || !hasRequiredScopes(sess.Scopes, ctx.OAuth2Scopes) || hasTokenExpired(sess.ExpiresAt) {
// ...
+ c.mu.Lock()
c.sessions[sessionKey] = s
+ c.mu.Unlock()
sess = s
}
// ...
}In AfterError:
func (c *clientCredentialsHook) AfterError(ctx AfterErrorContext, res *http.Response, err error) (*http.Response, error) {
// ...
if res != nil && res.StatusCode == http.StatusUnauthorized {
sessionKey := getSessionKey(credentials.ClientID, credentials.ClientSecret)
+ c.mu.Lock()
delete(c.sessions, sessionKey)
+ c.mu.Unlock()
}
// ...
}Committable suggestion was skipped due to low confidence.
| return &credentials{ | ||
| ClientID: *security.ClientID, | ||
| ClientSecret: *security.ClientSecret, | ||
| TokenURL: *security.GetTokenURL(), |
There was a problem hiding this comment.
Possible Nil Pointer Dereference in getCredentials
In line 207, you're dereferencing the result of security.GetTokenURL() without checking if it's nil. If GetTokenURL() returns nil, this could cause a panic. Ensure that GetTokenURL() cannot return nil, or add a nil check before dereferencing.
Consider modifying the code as follows:
tokenURL := security.GetTokenURL()
+ if tokenURL == nil {
+ return nil, fmt.Errorf("token URL is nil")
+ }
return &credentials{
ClientID: *security.ClientID,
ClientSecret: *security.ClientSecret,
- TokenURL: *security.GetTokenURL(),
+ TokenURL: *tokenURL,
}, nilCommittable suggestion was skipped due to low confidence.
flemzord
force-pushed
the
feat/add-scopes-in-openapi-spec
branch
from
fdf2ad6
to
184866c
Compare
Replace ECR public images with official golang and debian images to streamline the build process and reduce dependencies.
Remove the redundant initialization of httpTransport in the integration test setup to streamline the code and avoid unnecessary assignments. chore: clean up commented-out security in base.yaml Remove unnecessary commented-out security configurations in the base YAML release file to improve readability and maintainability.
flemzord
force-pushed
the
feat/add-scopes-in-openapi-spec
branch
from
184866c
to
75304cc
Compare
No description provided.