[Feature:System] Add verification of WebSocket pages

[lavalleeale]

Please check if the PR fulfills these requirements:

• Tests for the changes have been added/updated (if possible)
• Documentation has been updated/added if relevant
• Screenshots are attached to Github PR if visual/UI changes were made

What is the current behavior?

Any WebSocket page can be opened and monitored by anyone with the correct page name and basic authentication.

What is the new behavior?

Connection requests to a given WebSocket page are now entirely authorized through a WebSocket authorization token, managed by the web server. The proposed window for the token is 5 minutes, during which old authorized pages that have not been revisited within their expiration window will eventually be filtered out on the next token refresh request through a sliding window approach.

{
  "iat": 1753797357.504631,
  "iss": "http://localhost:1511/",
  "sub": "instructor",
  "authorized_pages": { 
    "f25-sample-chatrooms": 1753800957,
    "f25-sample-chatrooms-1": 1753800957,
    "f25-sample-polls-3-instructor": 1753800912
  },
  "expire_time": 1753800957
}

Other information?

This implementation replaces the original authorization logic with a JWT-based system, significantly reducing authentication time during WebSocket connection setup as we no longer make an external request to the database. The testing data is based on various new WebSocket page creations for new connections and page reload cases.

• Worst-Case:
  • Before: 1.814 ms
  • After: 0.386 ms
  • Percent Improvement: ~78.72%
• Best-Case:
  • Before: 0.701 ms
  • After: 0.069 ms
  • Percent Improvement: ~90.16%
• Average:
  • Before: 0.998 ms
  • After: 0.101 ms
  • Percent Improvement: ~89.86%

<Before>

0.829, 0.767, 0.993, 0.746, 0.811, 1.377, 0.813, 0.701, 0.843, 0.953,
0.805, 0.708, 0.754, 0.872, 0.717, 0.744, 0.742, 0.751, 1.152, 0.986,
0.776, 0.944, 1.048, 0.855, 0.992, 1.061, 0.834, 0.935, 1.035, 1.022, 
1.763, 0.954, 0.745, 1.102, 1.012, 1.088, 0.935, 1.279, 1.775, 1.241, 
1.150, 1.078, 1.458, 1.114, 1.001, 1.264, 1.814, 1.095, 0.755, 0.733

<After>

0.241, 0.078, 0.095, 0.087, 0.086, 0.082, 0.092, 0.096, 0.083, 0.087,
0.081, 0.077, 0.084, 0.086, 0.098, 0.085, 0.386, 0.077, 0.101, 0.081,
0.084, 0.108, 0.072, 0.073, 0.075, 0.088, 0.094, 0.089, 0.070, 0.069,
0.076, 0.080, 0.076, 0.079, 0.096, 0.073, 0.101, 0.097, 0.075, 0.085,
0.088, 0.085, 0.078, 0.078, 0.079, 0.157, 0.235, 0.126, 0.176, 0.115

[codecov]

Codecov Report

❌ Patch coverage is 24.51923% with 157 lines in your changes missing coverage. Please review.
✅ Project coverage is 21.70%. Comparing base (db9d942) to head (b33719f).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@             Coverage Diff              @@
##               main   #11634      +/-   ##
============================================
+ Coverage     21.66%   21.70%   +0.03%     
- Complexity     9531     9582      +51     
============================================
  Files           268      268              
  Lines         36395    36560     +165     
  Branches        475      475              
============================================
+ Hits           7886     7936      +50     
- Misses        28038    28153     +115     
  Partials        471      471              

Flag	Coverage Δ
autograder	21.31% <ø> (ø)
js	2.07% <ø> (ø)
migrator	100.00% <ø> (ø)
php	20.72% <24.51%> (+0.05%)	⬆️
python_submitty_utils	80.08% <ø> (ø)
submitty_daemon_jobs	90.72% <ø> (ø)

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[lavalleeale]

I can't approve or request changes since I technically am the author, but one change needs to get made and then it should be looking pretty good.

[martig7]

Maybe we should consider adding a method to revoke websocket tokens.

[martig7]

This PR makes multiple improvements to the ease of development of websocket features, and makes them more secure as well.

[cjreed121]

Overall, this looks good. Still looking at a couple security aspects. Left a couples comments and may have some more follow up once some questions are answered.

I think the short lived 5 minute tokens work fine but there is a downside to their lifetime. Sometimes the websocket server needs a manual restart (or has even crashed) which unfortunately drops all connections and makes everyone reconnect. With this approach, after 5 minutes of being on the page, they won't be able to reconnect until a page reload which is unfortunate. A good solution to this would be to recognize the expiration time or the auth failure, and request a new websocket token via AJAX. However this can definitely be a future improvement issue as this PR is already quite large.

[cjreed121]

Code looks good to me. No concerns security wise. Just one minor comment about the testing which can quickly be fixed (and worst case it could be addressed in a future PR). Note this is just a code review and I have not locally tested this.