| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
fix(file): copy templates remotely whenever remote storage is on (#7752) - `RemoteFileService.copy()` gated the blob-to-blob copy on `isCloud`, so a self-hosted or BYOC installation with S3, GCS or Azure configured never took that branch. Deploying a catalog template wrote the file to the server pod's local disk and stored `file_location = '_LOCAL_FILE_'`. The runner is a different pod, so the file was not there and the task sat in progress until the trigger gave up. ## Why `useRemote` is the right gate Every other method in the service already uses it, and `copy()` was the only one checking `isCloud` instead: | method | gate | |---|---| | `upload` | `!this.useRemote` | | `checkIfChanged` | `!this.useRemote` | | **`copy`** | **`isCloud`** | | `deleteFiles` | `!isCloud && !this.useRemote` | | `zipAndSendPublicFiles` | `!isCloud && !this.useRemote` | The method's own doc comment states the intent — *"This method handles when remote storage is not enabled (like locally)"* — so the `isCloud` check reads as a divergence rather than a decision. `useRemote` is computed once in the constructor: `useRemoteStorage` on enterprise (true when S3, GCS or Azure is configured), `!isLocal && !isTest` otherwise. **Cloud behaviour is unchanged**, since `useRemote` is already true there. ## How it was found On a BYOC installation with Azure Blob Storage, `nango deploy` from source worked — it goes through `upload()` and stored a real path: ``` noop | production/account/0/environment/2/config/1/noop-v1.0.0.js get-colors | _LOCAL_FILE_ list-issues | _LOCAL_FILE_ ``` Both template deploys got the marker, and triggering them returned `Task … is in progress` repeatedly. ## Test plan - [x] Reproduced on a BYOC installation with Azure Blob Storage configured - [ ] Template deploy records a `production/account/…` path rather than `_LOCAL_FILE_` - [ ] The copied blob exists under the account prefix - [ ] Triggering the deployed template action succeeds - [ ] Deploying from source still works, and cloud is unaffected 🤖 Generated with [Claude Code](https://claude.com/claude-code) <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/NangoHQ/nango/pull/7752?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com> | 1 天前 | |
[Github #627] shared refactor groundwork (#635) * [gh-#627] add shared package * [gh-#627] shared models refactor * [gh-#627] update refactor logic * [gh-#627] add references to shared * [gh-#627] copy shared package in the Dockerfile * [gh-#627] standardize tsconfig * [gh-#627] update db placement * [gh-#627] update build commands * [gh-#627] npm i before building * [gh-#627] move shard up * [gh-#627] reorder build * [gh-#627] fix commas * [gh-#627] set npm config prefix * [gh-#627] CI build of true * [gh-#627] type cleanup * [gh-#627] workspaces true * [gh-#627] update packages * [gh-#627] remove db * [gh-#627] update package ordering * [gh-#627] dot root directory | 3 年前 | |
chore(integration-templates): automatic update from https://github.com/NangoHQ/integration-templates/commit/ebea1712324b0f473d7d0a1572227cafecf62e76 by Hassan_Wari fix(gmail): fix emails sync (#385) | 1 年前 | |
chore(integration-templates): automatic update from https://github.com/NangoHQ/integration-templates/commit/73b6621f698206dbb7561601f031ab3af02c10e5 by Victor Lang'at feat: implement dynamic discovery of symlink mappings for integrations (#695) | 1 天前 | |
fix: more vulns (#7729) <!-- Describe the problem and your solution --> <!-- Issue ticket number and link (if applicable) --> <!-- Testing instructions (skip if just adding/editing providers) --> <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/NangoHQ/nango/pull/7729?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> | 2 天前 | |
feat(authz): add grant language and roles (NAN-6657) (#7218) First PR of an upcoming stack to unify API keys and RBAC under the same language. This adds the types, tweaks scopes and re-expresses the 3 RBAC roles in the new grant language. Nothing calls/uses these yet, this only contains the type definitions. The main type to look for is: ```ts interface Grant { can: ScopeSelector[]; // 'environment:connections:read', 'environment:*', '*' where: WhereSelector[]; // 'env:5', 'env:production', 'env:*', 'account', '*' } ``` We want keys to eventually hold an array of such grants, and for roles to be the same. Every endpoint would check for grants, resolved from the principal, be that from an api key or session token. ## Roles Since roles are a deny-map, and now they will flip to an allow-list, `roles.equivalence.unit.test.ts` (AI generated TBH) asserts there's no permission boundary change. The only intentional change is removing the ability for `production_support` to delete functions in production environments (which apparently slipped through in our current). ## Scopes We now have 3 scope lists: - public account plane - public environment plane - private scopes The account/env plane split is mostly utilitarian for now, we might merge them eventually. The private scopes is for scopes that only apply to private endpoints right now. The goal is to not have wildcards expanding to them, and for them to not be listed accidentally as available for public usage. As our public API surface expands, it is the goal for scopes to move from the private list into the public ones. Keeping them separate makes adding a new scope to the public realm intentional. Some private scopes where slightly renamed to match the pattern. ## "Issuable" Issuable means an API key can be issued with it. It's a little mechanism for us to explicitly disallow some things in the public API keys, while still having the "language" supporting RBAC cases. The private scopes described above are not issuable. I've also made wildcards on "where" not issuable: - `env:5` issuable: true - `account` issuable: true - `env:*` issuable: false - `env:production` issuable: false - `env:non-production` issuable: false - `*` issuable: false This is arguable. The reason is the "where" would grow and shrink causing potential issues: - A new env is added -> `env:*` expands it's reach. - An env is promoted to production -> `env:non-production` shrinks it's reach, something might break. This is a product decision though. I just thought it'd be wise to start more restrictive than less. ## Useful glossary - ConcreteScope -> an actual scope. Wildcards are not scopes. - ScopeSelector -> a scope, or a wildcard. Matches one or more ConcreteScopes - Issuable -> can be issued in an API key. Some things make sense in RBAC role, but we might want to artificially disallow in public keys. Examples of non-issuable are wildcards in "where", and private scopes. - Private scopes -> scopes that exist in the private API (RBAC), but not yet in the public API. Kept separate so that wildcards in the public API don't grow to them, and to avoid accidental exposure. ## Note This does not change the authz mechanism yet. It just defines the types and language. `can` is still used to authenticate private endpoints. <!-- This is an auto-generated description by cubic. --> <a href="https://cubic.dev/pr/NangoHQ/nango/pull/7218?utm_source=github" target="_blank" rel="noopener noreferrer" data-no-image-dialog="true"><picture><source media="(prefers-color-scheme: dark)" srcset="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"><source media="(prefers-color-scheme: light)" srcset="https://www.cubic.dev/buttons/review-in-cubic-light.svg"><img alt="Review in cubic" src="https://www.cubic.dev/buttons/review-in-cubic-dark.svg"></picture></a> <!-- End of auto-generated description by cubic. --> | 1 个月前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 1 天前 | ||
| 3 年前 | ||
| 1 年前 | ||
| 1 天前 | ||
| 2 天前 | ||
| 1 个月前 |