Programming exercises: Improve flexibility of authentication methods in the code popup

[SimonEntholzer]

Checklist

General

• I tested all changes and their related features with all corresponding user types on a test server.
• Language: I followed the guidelines for inclusive, diversity-sensitive, and appreciative language.
• I chose a title conforming to the naming conventions for pull requests.

Server

• Important: I implemented the changes with a very good performance and prevented too many (unnecessary) and too complex database calls.
• I strictly followed the principle of data economy for all database calls.
• I strictly followed the server coding and design guidelines.
• I documented the Java code using JavaDoc style.

Client

• Important: I implemented the changes with a very good performance, prevented too many (unnecessary) REST calls and made sure the UI is responsive, even with large data (e.g. using paging).
• I strictly followed the principle of data economy for all client-server REST calls.
• I strictly followed the client coding and design guidelines.
• Following the theming guidelines, I specified colors only in the theming variable files and checked that the changes look consistent in both the light and the dark theme.
• I added multiple integration tests (Jest) related to the features (with a high test coverage), while following the test guidelines.
• I documented the TypeScript code using JSDoc style.
• I added multiple screenshots/screencasts of my UI changes.
• I translated all newly inserted strings into English and German.

Changes affecting Programming Exercises

• High priority: I tested all changes and their related features with all corresponding user types on a test server configured with the integrated lifecycle setup (LocalVC and LocalCI).
• I tested all changes and their related features with all corresponding user types on a test server configured with Gitlab and Jenkins.

Motivation and Context

The code-button code is quite complex and bug prone.

Description

Fixes #9972
Adds the following features:

• in the .yml configuration admins can configure which authentication methods to use in a simple way, by providing an array, e.g. ['password', 'ssh', 'token']. The code button will also show these mechanisms in that order.
• The code button will remember the last used state, and use it as the default when opening the button.
• Makes a clear separation of token usage between courses and course-management routes. For course routes, the code-button uses the participation token, as this is the students view. For the instructor view, it always uses the user token.

Steps for Testing

Prerequisites:

1. Create a programming exercise
2. Participate as a student, by using the code button to clone the repository (SSH and via token)
3. As the instructor go to Course Management -> Exercises -> Participations, and use the clone button. Check if the token missing message is shown if your user does not have a user token (Settings -> VCS token)
4. Create a team programming exercise, create a team, and test the above steps

Exam Mode Testing

1. Create an exam with a programming exercise, participate as a student, and as an instructor check that you can use the code button in the participations view.

Testserver States

Note

These badges show the state of the test servers.
Green = Currently available, Red = Currently locked
Click on the badges to get to the test servers.

Review Progress

Code Review

• Code Review 1
• Code Review 2

Manual Tests

• Test 1
• Test 2

Test Coverage

Client

Class/File	Line Coverage	Confirmation (assert/expect)
repository-view.component.ts	98.19%	✅ ❌
code-button.component.ts	91.44%	✅ ❌
profile-info.model.ts	100%	✅
profile.service.ts	92.77%	✅ ❌

Screenshots

E.g. authentication set to ['ssh', 'token'], so the password/https option is not available:

Summary by CodeRabbit

Release Notes

• Authentication

  • Introduced a new configuration for authentication mechanisms.
  • Removed specific version control access token settings.

• User Interface

  • Updated repository link handling in various components.
  • Refined code button functionality across different views.
  • Enhanced visibility of programming exam summary section.
  • Removed repository password display options.

• Localization

  • Removed deprecated password-related translation entries.

• Access Control

  • Enhanced route protection for user settings based on user roles.

These changes enhance the authentication and repository access mechanisms, providing more flexible and streamlined user interactions.

[chrisknedl]

Code. Thanks for implementing my suggestions!

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (2)

src/test/java/de/tum/cit/aet/artemis/programming/icl/LocalVCInfoContributorTest.java (2)

16-21: Enhance test method clarity and maintainability.

1. The test method name testContribute is too generic. Consider renaming it to describe the specific behavior being tested, e.g., shouldContributeAuthenticationMechanismsToInfo.

2. Consider extracting the authentication mechanisms list as a constant or documenting why these specific values were chosen:

private static final List<String> EXPECTED_AUTHENTICATION_MECHANISMS = List.of("password", "token", "ssh");

3. The use of reflection might indicate that orderedAuthenticationMechanisms should be passed through the constructor or a setter method instead.

---

29-29: Enhance assertion specificity and error messages.

The current assertion could be more robust. Consider:

assertThat(info.getDetails())
    .as("Info details should not be null")
    .isNotNull()
    .containsKey("authenticationMechanisms");

assertThat(info.getDetails().get("authenticationMechanisms"))
    .as("Authentication mechanisms should match the configured values")
    .isNotNull()
    .isInstanceOf(List.class)
    .asList()
    .containsExactlyElementsOf(authenticationMechanisms);

This provides:

• Null checks
• Type verification
• More descriptive error messages
• Exact list comparison

📜 Review details

Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between f114d21 and 0bd00f0.

📒 Files selected for processing (1)

• src/test/java/de/tum/cit/aet/artemis/programming/icl/LocalVCInfoContributorTest.java (2 hunks)

🧰 Additional context used

📓 Path-based instructions (1)

src/test/java/de/tum/cit/aet/artemis/programming/icl/LocalVCInfoContributorTest.java (1)

Pattern src/test/java/**/*.java: test_naming: descriptive; test_size: small_specific; fixed_data: true; junit5_features: true; assert_use: assertThat; assert_specificity: true; archunit_use: enforce_package_rules; db_query_count_tests: track_performance; util_service_factory_pattern: true; avoid_db_access: true; mock_strategy: static_mocks; context_restart_minimize: true

⏰ Context from checks skipped due to timeout of 90000ms (9)

• GitHub Check: Codacy Static Code Analysis
• GitHub Check: server-tests
• GitHub Check: client-tests-selected
• GitHub Check: client-tests
• GitHub Check: client-style
• GitHub Check: server-style
• GitHub Check: Build and Push Docker Image
• GitHub Check: Build .war artifact
• GitHub Check: Analyse

🔇 Additional comments (1)

src/test/java/de/tum/cit/aet/artemis/programming/icl/LocalVCInfoContributorTest.java (1)

Line range hint 1-13: LGTM! Clean imports and proper class structure.

The imports are well-organized, and the test class follows proper naming conventions.

[dfuchss]

Code looks good overall. Just two minor remarks from my side. I also have a general question: Since personal access tokens are not used for students anymore, would it make sense to add a guard to the /user-settings/vcs-token path, so that students can't access it via the url? This is currently still possible.

That's a good point, this would make sense now. I added it that students can now no longer access these settings via path.

The API is still accessible for Instructors and Teaching Assistants, right? Because we rely on this API.

[SimonEntholzer]

Code looks good overall. Just two minor remarks from my side. I also have a general question: Since personal access tokens are not used for students anymore, would it make sense to add a guard to the /user-settings/vcs-token path, so that students can't access it via the url? This is currently still possible.

That's a good point, this would make sense now. I added it that students can now no longer access these settings via path.

The API is still accessible for Instructors and Teaching Assistants, right? Because we rely on this API.

Yes, that only affects users which exclusively have the student role.

The API itself wasn't touched at all here tbh., only the routing to the token settings. So TAs and instructors are not affected in any way.

[az108]

Code reapprove 👍

[BBesrour]

re-approve

[chrisknedl]

Re-approve

[ole-ve]

code re-approve

[Cathy0123456789]

Tested on TS2. Cloning code by Token works as student. As instructor wanting to check out the student's repository without a VCS Token the warning is shown

[b-fein]

application-localvc.yml still refers to the old now unused values, rather than the single new one.