-
Notifications
You must be signed in to change notification settings - Fork 451
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(integrations): Readwise APIs #3231
base: master
Are you sure you want to change the base?
feat(integrations): Readwise APIs #3231
Conversation
authorization: Token ${apiKey} | ||
verification: | ||
method: GET | ||
endpoint: https://readwise.io/api/v2/auth |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
the v3 api still uses the v2/auth for verification, is it ok to have the full url like this? or will it lead to a bug i.e. https://readwise.io/api/v3/https://readwise.io/api/v2/auth
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good question, we need to check
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From reading the code I think on the verification block you can set base_url_override
and it will use that on verify.
See
nango/packages/server/lib/hooks/hooks.ts
Line 229 in b61728b
const { method, endpoint, base_url_override: baseUrlOverride, headers } = providerVerification; |
packages/webapp/public/images/template-logos/readwise-reader.svg
Outdated
Show resolved
Hide resolved
authorization: Token ${apiKey} | ||
verification: | ||
method: GET | ||
endpoint: https://readwise.io/api/v2/auth |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good question, we need to check
|
GitGuardian id | GitGuardian status | Secret | Commit | Filename | |
---|---|---|---|---|---|
8205899 | Triggered | Generic Password | c3582ef | packages/cli/docker/docker-compose.yaml | View secret |
🛠 Guidelines to remediate hardcoded secrets
- Understand the implications of revoking this secret by investigating where it is used in your code.
- Replace and store your secret safely. Learn here the best practices.
- Revoke and rotate this secret.
- If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.
To avoid such incidents in the future consider
- following these best practices for managing and storing secrets including API keys and other credentials
- install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.
🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.
Added Readwise integration with support for both Readwise API (v2) and Readwise Reader API (v3)
The Readwise API (v2) enables access to highlights and books data, while the Reader API (v3) allows saving and fetching documents in Readwise Reader.