chore(auth): loading github module optionally

[HarshPatel5940]

User description

Description

This pull request refactors the Github authentication module to load the Github module optionally. It also adds a new service called GithubEnvService to handle Github environment configurations. The GithubStrategy class now accepts the Github credentials as constructor parameters. Additionally, the AuthController now checks if Github login is enabled before redirecting to the Github OAuth endpoint.

Fixes #107

Dependencies

no

Mentions

@rajdip-b

Developer's checklist

• My PR follows the style guidelines of this project

• I have performed a self-check on my work

• I have followed the coding guidelines

• My changes in code generate no new warnings

• My changes are breaking another fix/feature of the project

• I have added test cases to show that my feature works

• I have added relevant screenshots in my PR

• There are no UI/UX issues

Documentation Update

• This PR requires an update to the documentation at docs.keyshade.xyz
• I have made the necessary updates to the documentation, or no documentation changes are required.

---

Type

enhancement, documentation

---

Description

• Refactored GitHub authentication to use GithubOAuthStratergyFactory for dynamic strategy creation based on environment configuration.
• Introduced ConfigModule to manage OAuth strategies, including GitHub.
• Enhanced AuthController to check if GitHub authentication is enabled before proceeding with OAuth flow.
• Added new tests and updated existing ones to accommodate changes in authentication flow.
• Documentation should be updated to reflect changes in GitHub OAuth setup and configuration.

---

Changes walkthrough

	Relevant files
Enhancement	auth.module.ts Refactor AuthModule to Use GithubOAuthStrategyFactory                    apps/api/src/auth/auth.module.ts Refactored to use GithubOAuthStratergyFactory for creating GithubStrategy. Updated providers to include GithubOAuthStratergyFactory and dynamically create GithubStrategy. +13/-2    auth.controller.ts Enhance GitHub OAuth Login Flow with Enablement Check                    apps/api/src/auth/controller/auth.controller.ts Added GithubOAuthStratergyFactory to constructor for checking GitHub OAuth enablement. Modified githubOAuthLogin to check if GitHub Auth is enabled before proceeding. +16/-8    config.module.ts Introduce ConfigModule for GitHub OAuth Strategy                              apps/api/src/config/config.module.ts Introduced ConfigModule to provide GithubStrategy and GithubOAuthStratergyFactory. +9/-0      github-stratergy.factory.ts Implement GithubOAuthStrategyFactory for Dynamic Strategy Creation apps/api/src/config/factory/github-stratergy.factory.ts Implemented GithubOAuthStratergyFactory for creating GitHub strategy based on environment config. Added methods to check if GitHub config exists and to create OAuth strategy. +54/-0    oauth-stratergy.factory.ts Define OAuthStrategyFactory Interface                                                    apps/api/src/config/factory/oauth-stratergy.factory.ts Defined OAuthStratergyFactory interface for OAuth strategy creation. +5/-0      github.stratergy.ts Refactor GitHub Strategy to Use Constructor Parameters                  apps/api/src/config/oauth-stratergy/github.stratergy.ts Refactored to accept credentials via constructor instead of ConfigService. Updated validate method signature for clarity. +6/-6
Tests	auth.controller.spec.ts Update AuthController Tests with New Dependencies                            apps/api/src/auth/controller/auth.controller.spec.ts Added GithubOAuthStratergyFactory and ConfigService to providers in tests. +4/-0

---

✨ Usage guide:

---

Overview:
The describe tool scans the PR code changes, and generates a description for the PR - title, type, summary, walkthrough and labels. The tool can be triggered automatically every time a new PR is opened, or can be invoked manually by commenting on a PR.

When commenting, to edit configurations related to the describe tool (pr_description section), use the following template:

/describe --pr_description.some_config1=... --pr_description.some_config2=...

With a configuration file, use the following template:

[pr_description]
some_config1=...
some_config2=...

Enabling\disabling automation When you first install the app, the default mode for the describe tool is: pr_commands = ["/describe --pr_description.add_original_user_description=true" "--pr_description.keep_original_user_title=true", ...] meaning the describe tool will run automatically on every PR, will keep the original title, and will add the original user description above the generated description. Markers are an alternative way to control the generated description, to give maximal control to the user. If you set: pr_commands = ["/describe --pr_description.use_description_markers=true", ...] the tool will replace every marker of the form pr_agent:marker_name in the PR description with the relevant content, where marker_name is one of the following: type: the PR type. summary: the PR summary. walkthrough: the PR walkthrough. Note that when markers are enabled, if the original PR description does not contain any markers, the tool will not alter the description at all.

Custom labels The default labels of the describe tool are quite generic: [Bug fix, Tests, Enhancement, Documentation, Other]. If you specify custom labels in the repo's labels page or via configuration file, you can get tailored labels for your use cases. Examples for custom labels: Main topic:performance - pr_agent:The main topic of this PR is performance New endpoint - pr_agent:A new endpoint was added in this PR SQL query - pr_agent:A new SQL query was added in this PR Dockerfile changes - pr_agent:The PR contains changes in the Dockerfile ... The list above is eclectic, and aims to give an idea of different possibilities. Define custom labels that are relevant for your repo and use cases. Note that Labels are not mutually exclusive, so you can add multiple label categories. Make sure to provide proper title, and a detailed and well-phrased description for each label, so the tool will know when to suggest it.

Inline File Walkthrough 💎 For enhanced user experience, the describe tool can add file summaries directly to the "Files changed" tab in the PR page. This will enable you to quickly understand the changes in each file, while reviewing the code changes (diffs). To enable inline file summary, set pr_description.inline_file_summary in the configuration file, possible values are: 'table': File changes walkthrough table will be displayed on the top of the "Files changed" tab, in addition to the "Conversation" tab. true: A collapsable file comment with changes title and a changes summary for each file in the PR. false (default): File changes walkthrough will be added only to the "Conversation" tab.

Utilizing extra instructions The describe tool can be configured with extra instructions, to guide the model to a feedback tailored to the needs of your project. Be specific, clear, and concise in the instructions. With extra instructions, you are the prompter. Notice that the general structure of the description is fixed, and cannot be changed. Extra instructions can change the content or style of each sub-section of the PR description. Examples for extra instructions: [pr_description] extra_instructions=""" - The PR title should be in the format: '<PR type>: <title>' - The title should be short and concise (up to 10 words) - ... """ Use triple quotes to write multi-line instructions. Use bullet points to make the instructions more readable.

More PR-Agent commands To invoke the PR-Agent, add a comment using one of the following commands: /review: Request a review of your Pull Request. /describe: Update the PR title and description based on the contents of the PR. /improve [--extended]: Suggest code improvements. Extended mode provides a higher quality feedback. /ask <QUESTION>: Ask a question about the PR. /update_changelog: Update the changelog based on the PR's contents. /add_docs 💎: Generate docstring for new components introduced in the PR. /generate_labels 💎: Generate labels for the PR based on the PR's contents. /analyze 💎: Automatically analyzes the PR, and presents changes walkthrough for each component. See the tools guide for more details. To list the possible configuration parameters, add a /config comment.

See the describe usage page for a comprehensive guide on using this tool.

[nx-cloud]

☁️ Nx Cloud Report

CI is running/has finished running commands for commit d82a2e2. As they complete they will appear below. Click to see the status, the terminal output, and the build insights.

📂 See all runs for this CI Pipeline Execution

---

✅ Successfully ran 4 targets

• nx run api:test:e2e -- --coverage --coverageDirectory=coverage-e2e/api --coverageReporters=json -- --no-cache
• nx run api:test -- --coverage --coverageDirectory=coverage/api --coverageReporters=json -- --no-cache
• nx run api:prisma:generate
• nx run api:lint

---

Sent with 💌 from NxCloud.

[codecov]

Codecov Report

Attention: 24 lines in your changes are missing coverage. Please review.

Comparison is base (ae73e7a) 31.22% compared to head (0de121d) 54.46%.
Report is 3 commits behind head on develop.

❗ Current head 0de121d differs from pull request most recent head d82a2e2. Consider uploading reports for the commit d82a2e2 to get more accurate results

Files	Patch %	Lines
apps/api/src/auth/guard/auth/auth.guard.ts	65.78%	13 Missing ⚠️
apps/api/src/auth/controller/auth.controller.ts	57.14%	3 Missing ⚠️
apps/api/src/auth/service/auth.service.ts	0.00%	3 Missing ⚠️
apps/api/src/api-key/service/api-key.service.ts	50.00%	2 Missing ⚠️
apps/api/src/auth/guard/api-key/api-key.guard.ts	92.30%	2 Missing ⚠️
...rc/config/oauth-strategy/github/github.strategy.ts	50.00%	1 Missing ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##           develop     #112       +/-   ##
============================================
+ Coverage    31.22%   54.46%   +23.23%     
============================================
  Files           54       73       +19     
  Lines         1156     1366      +210     
  Branches       210      233       +23     
============================================
+ Hits           361      744      +383     
+ Misses         795      622      -173     

Flag	Coverage Δ
api-e2e-tests	53.24% <80.00%> (?)
api-unit-tests	33.09% <52.71%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[rajdip-b]

Alright I went through the changes, and the logic looks fine to me. (Thanks for the screenshot ❤️ )

Here's a list of things I would like you to do to make this complete:

• Create another module named config: cd apps/api && nest g module config
• Create a folder named oauth-stratergy and move the github.stratergy.ts file to this folder
• Create a folder inside that module named factory
• Add an interface inside it named OAuthStratergyFactory (oauth-stratergy.factory.ts) with just one function in it -> <T extends PassportStratergy> createOAuthStratergy(): T
• Add a service class named GitHubOAuthStratergyFactory (github-stratergy.factory.ts) in the factory folder, implement the OAuthStratergy interface, and combine the code that you wrote in GithubEnvService. This new factory class will have two roles: a private function to check if github is enabled or not, a public function createOAuthStratergy that will do the work you are currently doing in the provider section of the auth.module.ts file.
• Export these files from the config folder using the exports array.
• Import them in the auth.module.ts and fill in the gaps

If you can spot, I'm motivating you to use factory pattern for this one. This is for a bigger cause:

• We will have multiple auth providers in future (even metamask wallet)
• We will have a couple of services (sentry for example) that we would want to configure in a similar manner.

Your PR here would lay down the fundamentals of a very big architecture of our repository ❤️

[HarshPatel5940]

Thank you @rajdip-b for your time writing these detailed steps, it will immensely help me. I will make the necessary changes as soon as time permits and let you know here.

[codiumai-pr-agent-free]

PR Description updated to latest commit (97e53a4)

[codiumai-pr-agent-free]

PR Analysis

• 🎯 Main theme: Refactoring the Github authentication module to load the Github module optionally and introducing a new service to handle Github environment configurations.
• 📝 PR summary: This PR refactors the Github authentication module to load the Github module optionally. It introduces a new service called GithubEnvService to handle Github environment configurations. The GithubStrategy class now accepts the Github credentials as constructor parameters. The AuthController now checks if Github login is enabled before redirecting to the Github OAuth endpoint.
• 📌 Type of PR: Enhancement
• 🧪 Relevant tests added: No
• ⏱️ Estimated effort to review [1-5]: 3, because the PR involves changes in the authentication flow and introduces a new service. It requires a good understanding of the existing authentication mechanism and the OAuth process.
• 🔒 Security concerns: No

PR Feedback

💡 General suggestions: The code changes seem to be well-structured and follow good practices. However, there are a few areas that could be improved:

• The GithubOAuthStratergyFactory class has a method createOAuthStratergy that returns null if the OAuth is not enabled. This could potentially lead to null pointer exceptions. Consider throwing an exception or returning a default strategy.
• The AuthController class has a method githubOAuthLogin that throws an exception if Github login is not enabled. It would be better to handle this scenario gracefully, perhaps by redirecting the user to an error page or displaying a meaningful message.
• It's not clear if the new GithubEnvService is used anywhere. If it's not used, consider removing it.
• The PR lacks tests for the new functionality. It's important to add tests to ensure the new functionality works as expected and doesn't break anything.

---

✨ Usage guide:

---

Overview:
The review tool scans the PR code changes, and generates a PR review. The tool can be triggered automatically every time a new PR is opened, or can be invoked manually by commenting on any PR.
When commenting, to edit configurations related to the review tool (pr_reviewer section), use the following template:

/review --pr_reviewer.some_config1=... --pr_reviewer.some_config2=...

With a configuration file, use the following template:

[pr_reviewer]
some_config1=...
some_config2=...

Utilizing extra instructions The review tool can be configured with extra instructions, which can be used to guide the model to a feedback tailored to the needs of your project. Be specific, clear, and concise in the instructions. With extra instructions, you are the prompter. Specify the relevant sub-tool, and the relevant aspects of the PR that you want to emphasize. Examples for extra instructions: [pr_reviewer] # /review # extra_instructions=""" In the 'general suggestions' section, emphasize the following: - Does the code logic cover relevant edge cases? - Is the code logic clear and easy to understand? - Is the code logic efficient? ... """ Use triple quotes to write multi-line instructions. Use bullet points to make the instructions more readable.

How to enable\disable automation When you first install PR-Agent app, the default mode for the review tool is: pr_commands = ["/review", ...] meaning the review tool will run automatically on every PR, with the default configuration. Edit this field to enable/disable the tool, or to change the used configurations

Auto-labels The review tool can auto-generate two specific types of labels for a PR: a possible security issue label, that detects possible security issues (enable_review_labels_security flag) a Review effort [1-5]: x label, where x is the estimated effort to review the PR (enable_review_labels_effort flag)

Extra sub-tools The review tool provides a collection of possible feedbacks about a PR. It is recommended to review the possible options, and choose the ones relevant for your use case. Some of the feature that are disabled by default are quite useful, and should be considered for enabling. For example: require_score_review, require_soc2_ticket, and more.

Auto-approve PRs By invoking: /review auto_approve The tool will automatically approve the PR, and add a comment with the approval. To ensure safety, the auto-approval feature is disabled by default. To enable auto-approval, you need to actively set in a pre-defined configuration file the following: [pr_reviewer] enable_auto_approval = true (this specific flag cannot be set with a command line argument, only in the configuration file, committed to the repository) You can also enable auto-approval only if the PR meets certain requirements, such as that the estimated_review_effort is equal or below a certain threshold, by adjusting the flag: [pr_reviewer] maximal_review_effort = 5

More PR-Agent commands To invoke the PR-Agent, add a comment using one of the following commands: /review: Request a review of your Pull Request. /describe: Update the PR title and description based on the contents of the PR. /improve [--extended]: Suggest code improvements. Extended mode provides a higher quality feedback. /ask <QUESTION>: Ask a question about the PR. /update_changelog: Update the changelog based on the PR's contents. /add_docs 💎: Generate docstring for new components introduced in the PR. /generate_labels 💎: Generate labels for the PR based on the PR's contents. /analyze 💎: Automatically analyzes the PR, and presents changes walkthrough for each component. See the tools guide for more details. To list the possible configuration parameters, add a /config comment.

See the review usage page for a comprehensive guide on using this tool.

[codiumai-pr-agent-free]

PR Code Suggestions

	Suggestions
maintainability	Use more descriptive variable names for clarity.                              Consider using a more descriptive variable name than stratergy in the useFactory function to enhance code readability. For example, githubOAuthStrategyFactory would make it immediately clear what type of strategy the factory is creating. apps/api/src/auth/auth.module.ts [27-28] -useFactory: (stratergy: GithubOAuthStratergyFactory) => { - stratergy.createOAuthStratergy() +useFactory: (githubOAuthStrategyFactory: GithubOAuthStratergyFactory) => { + githubOAuthStrategyFactory.createOAuthStratergy() }
best practice	Use NestJS's built-in redirection mechanism for cleaner code.                 Replace the direct use of @Res() and manual response handling in githubOAuthLogin with NestJS's built-in redirection mechanism by returning a RedirectResponse object. This approach is more idiomatic to NestJS and leverages its built-in response handling capabilities. apps/api/src/auth/controller/auth.controller.ts [98-106] -async githubOAuthLogin(@Res() res) { +async githubOAuthLogin() { if (!this.githubStrategy.checkIfEnabled()) { throw new HttpException( 'GitHub Auth is not enabled in this environment. Refer to the https://docs.keyshade.xyz/contributing-to-keyshade/environment-variables if you would like to set it up.', HttpStatus.BAD_REQUEST ) } - res.status(302).redirect('/api/auth/github/callback') + return { url: '/api/auth/github/callback', statusCode: 302 } } Add type annotations to method parameters for clarity.                        Add type annotations to the parameters of the validate method to improve code readability and maintainability. This will make it clear what types of arguments are expected by the method. apps/api/src/config/oauth-stratergy/github.stratergy.ts [16-22] async validate( _accessToken: string, _refreshToken: string, profile: Profile -) { +): Promise<any> { return profile } Mock external dependencies in unit tests for isolation.                       Consider mocking GithubOAuthStratergyFactory in your test setup to ensure that your unit tests for AuthController are not dependent on the actual implementation of GitHub OAuth strategy. This will make your tests more reliable and focused on the controller's behavior. apps/api/src/auth/controller/auth.controller.spec.ts [18-24] providers: [ AuthService, - GithubOAuthStratergyFactory, + { provide: GithubOAuthStratergyFactory, useValue: mockGithubOAuthStratergyFactory }, ConfigService, { provide: MAIL_SERVICE, useClass: MockMailService }, JwtService, PrismaService ]
possible issue	Add error handling for when GitHub Auth is not enabled.                       Implement error handling for the scenario where createOAuthStratergy returns null due to GitHub Auth not being enabled. This will prevent potential runtime errors in parts of the application that rely on the existence of a strategy. apps/api/src/config/factory/github-stratergy.factory.ts [37-51] -public createOAuthStratergy<T extends typeof PassportStrategy>(): T { +public createOAuthStratergy<T extends typeof PassportStrategy>(): T | never { if (this.isOAuthEnabled) { const creds = this.getGithubCredentials() return new GithubStrategy( creds.clientID, creds.clientSecret, creds.callbackURL ) as unknown as T } else { - Logger.warn( + Logger.error( 'GitHub Auth is not enabled in this environment. Refer to the https://docs.keyshade.xyz/contributing-to-keyshade/environment-variables if you would like to set it up.' ) - return null + throw new Error('GitHub Auth is not enabled in this environment.') } }

---

✨ Usage guide:

---

Overview:
The improve tool scans the PR code changes, and automatically generates suggestions for improving the PR code. The tool can be triggered automatically every time a new PR is opened, or can be invoked manually by commenting on a PR.
When commenting, to edit configurations related to the improve tool (pr_code_suggestions section), use the following template:

/improve --pr_code_suggestions.some_config1=... --pr_code_suggestions.some_config2=...

With a configuration file, use the following template:

[pr_code_suggestions]
some_config1=...
some_config2=...

Enabling\disabling automation When you first install the app, the default mode for the improve tool is: pr_commands = ["/improve --pr_code_suggestions.summarize=true", ...] meaning the improve tool will run automatically on every PR, with summarization enabled. Delete this line to disable the tool from running automatically.

Utilizing extra instructions Extra instructions are very important for the improve tool, since they enable to guide the model to suggestions that are more relevant to the specific needs of the project. Be specific, clear, and concise in the instructions. With extra instructions, you are the prompter. Specify relevant aspects that you want the model to focus on. Examples for extra instructions: [pr_code_suggestions] # /improve # extra_instructions=""" Emphasize the following aspects: - Does the code logic cover relevant edge cases? - Is the code logic clear and easy to understand? - Is the code logic efficient? ... """ Use triple quotes to write multi-line instructions. Use bullet points to make the instructions more readable.

A note on code suggestions quality While the current AI for code is getting better and better (GPT-4), it's not flawless. Not all the suggestions will be perfect, and a user should not accept all of them automatically. Suggestions are not meant to be simplistic. Instead, they aim to give deep feedback and raise questions, ideas and thoughts to the user, who can then use his judgment, experience, and understanding of the code base. Recommended to use the 'extra_instructions' field to guide the model to suggestions that are more relevant to the specific needs of the project, or use the custom suggestions 💎 tool With large PRs, best quality will be obtained by using 'improve --extended' mode.

More PR-Agent commands To invoke the PR-Agent, add a comment using one of the following commands: /review: Request a review of your Pull Request. /describe: Update the PR title and description based on the contents of the PR. /improve [--extended]: Suggest code improvements. Extended mode provides a higher quality feedback. /ask <QUESTION>: Ask a question about the PR. /update_changelog: Update the changelog based on the PR's contents. /add_docs 💎: Generate docstring for new components introduced in the PR. /generate_labels 💎: Generate labels for the PR based on the PR's contents. /analyze 💎: Automatically analyzes the PR, and presents changes walkthrough for each component. See the tools guide for more details. To list the possible configuration parameters, add a /config comment.

See the improve usage page for a more comprehensive guide on using this tool.

[rajdip-b]

Awesome man @HarshPatel5940 !! Really thanks for doing all this.

[HarshPatel5940]

Awesome man @HarshPatel5940 !! Really thanks for doing all this.

Thanks to you as well for the detailed review!

[rajdip-b]

@HarshPatel5940 I'm working on another branch that aims to fix some issues with the CI and also add a functionality to the api-keys. Once that's done, I'll update your branch and make the review again!

[sonarqubecloud]

Quality Gate failed

Failed conditions

3.7% Duplication on New Code (required ≤ 3%)
25 Duplicated Lines on New Code (required ≤ 20)

See analysis details on SonarCloud

[rajdip-b]

🎉 This PR is included in version 1.0.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀