Programming exercises: Add tool token support

[janthoXO]

Tip

This PR stacks on top of feature/bearer-support

Checklist

General

• I tested all changes and their related features with all corresponding user types on a test server.
• This is a small issue that I tested locally and was confirmed by another developer 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 added multiple integration tests (Spring) related to the features (with a high test coverage).
• I added pre-authorization annotations according to the guidelines and checked the course groups for all new REST Calls (security).
• 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 added authorities to all new routes and checked the course groups for displaying navigation elements (links, buttons).
• 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.

Description

Adds an endpoint to generate a new token based on the old token.
This is primarily needed for the online IDE, to pass the artemis token in the redirect

Steps for Testing

Code reviews or testing in Postman with both as-bearer and without would be nice

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

Performance Review

• I (as a reviewer) confirm that the client changes (in particular related to REST calls and UI responsiveness) are implemented with a very good performance even for very large courses with more than 2000 students.
• I (as a reviewer) confirm that the server changes (in particular related to database calls) are implemented with a very good performance even for very large courses with more than 2000 students.

Code Review

• Code Review 1
• Code Review 2

Manual Tests

• Test 1
• Test 2

Exam Mode Test

• Test 1
• Test 2

Performance Tests

• Test 1
• Test 2

Test Coverage

Screenshots

Summary by CodeRabbit

Release Notes

• New Features

  • Introduced a new method to create JWT cookies with a specific "THEIA" flag.
  • Added functionality to retrieve a Theia token, which can be returned as a cookie or bearer token.

• Improvements

  • Enhanced JWT extraction and validation process, allowing for tokens to be checked from both cookies and Authorization headers.
  • Updated response handling in the authorization method to return the cookie value instead of an empty response.

• Bug Fixes

  • Improved error handling for invalid JWT tokens in the new token retrieval method.

[krusche]

As discussed before, I do not think that it is a good idea to offer a re-key functionality from a security point of view. Therefore, I would like to decline this PR and close it.

[janthoXO]

As discussed before, I do not think that it is a good idea to offer a re-key functionality from a security point of view. Therefore, I would like to decline this PR and close it.

its still a draft, so I would like to first have a discussion about it, before declining this PR.

[krusche]

As discussed before, I do not think that it is a good idea to offer a re-key functionality from a security point of view. Therefore, I would like to decline this PR and close it.

its still a draft, so I would like to first have a discussion about it, before declining this PR.

We discussed this already several times. I'm not sure if additional discussions help, when my arguments against it are ignored :-(

[janthoXO]

We discussed this already several times. I'm not sure if additional discussions help, when my arguments against it are ignored :-(

we agreed on a meeting in the afternoon, so please let us have this meeting first

[janthoXO]

After the meeting the proposed solution looks as follows:

• re-key is a suboptimal name since it is only used for theia. therefore the endpoint should be renamed
• the token lifetime should not be extended - best case the token should be valid at max for 1 day
• the token should contain a theia specific flag
• the whole functionality depends on the theia profile being active
• the token is a standard artemis token inheriting all of the original tokens capabilities

@krusche will provide further feedback on that

[janthoXO]

TODO, make endpoint only available if theia profile is active

[github-actions]

There hasn't been any activity on this pull request recently. Therefore, this pull request has been automatically marked as stale and will be closed if no further activity occurs within seven days. Thank you for your contributions.