docs: add security notes to docs#1218
Conversation
|
Preview deployment for your docs. Learn more about Mintlify Previews.
💡 Tip: Enable Workflows to automatically generate PRs for you. |
This comment has been minimized.
This comment has been minimized.
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
WalkthroughThis PR adds clarifying documentation: a "Session lifetime" note describing default 30-day cookie validity and JWT clock-skew tolerance, and expanded permission-syncing docs covering Bitbucket Cloud closed-account behavior, connection-resync repository visibility timing, added user-driven sync interval, and fail-closed error semantics. ChangesAuthentication and Permission Feature Documentation
🎯 2 (Simple) | ⏱️ ~10 minutes 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 inconclusive)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/docs/configuration/auth/overview.mdx`:
- Line 27: Rewrite the Note block so it speaks directly to the reader in second
person and uses short, direct sentences: start by telling the user that their
session cookie is guaranteed valid for at least AUTH_SESSION_MAX_AGE_SECONDS,
then add a separate sentence that explains it may still be accepted briefly
after that, and finish with a short sentence noting this is due to the JWT
verifier applying a small clock‑skew tolerance when checking expiry. Use "you"
phrasing and keep each idea in its own concise sentence.
In `@docs/docs/features/permission-syncing.mdx`:
- Line 105: Rewrite the Note block text into short, second-person, present-tense
sentences: replace third-person phrasing like “Bitbucket Cloud account is closed
by its owner” with direct “When you close a Bitbucket Cloud account…” and
shorten into two or three concise sentences that state the behavior and action
(e.g., you may still appear in repo permission lists during Atlassian’s grace
period; Sourcebot revokes your access after the next permission sync that
returns an authentication error or when Atlassian purges the account). Do the
same for the two other similar note blocks referenced in the file (the later
notes around the other occurrences) so all notes use “you,” present tense, and
tighter sentence structure.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: CHILL
Plan: Pro
Run ID: bc615d7e-14e8-4c0c-b6cc-0ae3d9c0e3ec
📒 Files selected for processing (2)
docs/docs/configuration/auth/overview.mdxdocs/docs/features/permission-syncing.mdx
Five small Note cards documenting accepted security trade-offs that surfaced during the BB Cloud profile acceptance run, so customers can plan for them without surprise. None are bugs to fix; they are upstream constraints or design choices worth flagging in-line where users would otherwise have to derive them empirically. - Session lifetime: JWT verifier clock-skew tolerance means sessions may be accepted briefly past AUTH_SESSION_MAX_AGE_SECONDS. - Bitbucket Cloud: Atlassian's 14-day account-deletion grace period can leave a closed user in BB permission lists until purge or until the next permission sync sees an auth error. - enforcePermissionsForPublicRepos: clarify that this is a host-level membership check, not a per-repo permission check. - Visibility changes are refreshed by connection sync, not permission sync, so public/private flips converge on resyncConnectionIntervalMs. - Permission sync fails closed only on auth-related errors; transient rate-limit and 5xx responses leave the previous state in effect. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
efdad7f to
2acf7ca
Compare
Summary by CodeRabbit