-
Notifications
You must be signed in to change notification settings - Fork 1.9k
Feat: bitbucket app #4214
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
base: main
Are you sure you want to change the base?
Feat: bitbucket app #4214
Conversation
if res.StatusCode >= 200 && res.StatusCode < 300 || res.StatusCode == 403 { | ||
s1.Verified = true | ||
} |
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.
Instead of using a broad conditional to check status codes, consider switching to a switch statement that explicitly handles expected responses like 200 OK and 401 Unauthorized. This makes the code easier to read, and allows for structured handling of each response case. It also ensures that unexpected status codes are surfaced clearly, which helps with debugging and observability.
Here's an example
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.
Swapped. Did keep 200, 403 grouped in the switch block as they both return true.
Raw: []byte(fmt.Sprintf(`%s: %s`, resUsernameMatch, resAppPasswordMatch)), | ||
} | ||
|
||
if verify { |
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.
nit; In our new detectors, we do verification separately, see this
pkg/detectors/bitbucketapppassword/bitbucketapppassword_test.go
Outdated
Show resolved
Hide resolved
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.
We should also have a bitbucketapppassword_test.go
for pattern test. See this
64a0e95
to
c23bcf2
Compare
134bd62
to
1864c95
Compare
Co-authored-by: Amaan Ullah <amaanuj.dev@gmail.com>
1864c95
to
6ecce5f
Compare
- add switch{} block + credentialPattern[] for readability - + tidy nested loops - reflect codebase conventions in verification scope - hard drain io.Discard, body.Close on res call in verify func - intro the patterns test as it was not introoed - standardize the integration test based off others living in repo
6ecce5f
to
340b046
Compare
ran some benchmarks
still not really satisfied as these regexes are quite slow. @amanfcp, thx for the pointers, I tried to port the feedback in while going through some more recently added detectors. |
fork off brandonjyan:bitbucketapppassword which lived here #1498
The previous complex logic has been replaced with a clean, single-pass approach using a unified credentialPatterns slice for simplicity and performance.
The entire detector has been brought up to current project standards, attempt w/ cleaner regex with named capture groups and improved resource handling.
xxlarge bench is 2x faster.
Checklist:
[ ✔️ ] Tests passing (
make test-community
)?[ ✔️ ] Lint passing (
make lint
this requires golangci-lint)?