Adds Problem XBlock extracting from edx-platform repo

[irtazaakram]

Adds Problem XBlock extracting from edx-platform repo

Description

Test PR

Make a test PR on edx-platform like this to run test cases on under development PR.

File references:

• xblocks_contrib/problem/problem.py has been extracted from
• xblocks_contrib/problem/capa has been extracted from

Acceptance Criteria:

• Extracted XBlock user experience should behave normal if required global css variables donesn't exist
• Extracted XBlock funcationality should work fine after turning its relevant Django Settings Flag
• In existing built in xblock implementation of edx-platform, update the status or data of the XBlocks. Then change the Django Settings flag and verify after shifting to extracted one, XBlocks are maintaining their required states (including XBlock completion status).
• Also test the vice versa of above step, change XBlock from Extracted one to Built in implementation to check fallback case testings.
• i18n is supported in the XBlock
• Create a course, add multiple XBlocks in the course. Keep different XBlocks in diversity of states (done/un-done etc). Export the course then validate the XBlock states after importing it again.
• Make a test PR for the extracted PR like this and fix the test cases if required.
• Write further unit test cases for good code coverage

Relevant Issue: openedx/edx-platform#36538

[salman2013]

@irtazaakram could you look into conflicts.

[salman2013]

@irtazaakram On studio this error is showing

I think the file you are adding here on line 611 is missing in the code. could you please check it?

[kdmccormick]

Nice, could we get this CI check merged by a separate PR as a soon as possible so that JS tests run for other PRs too?

[irtazaakram]

It's already merged in main. PR https://github.com/openedx/xblocks-contrib/pull/91/files.

[kdmccormick]

The extracted ProblemBlock code cannot import from openedx, as that would be a circular dependency between edx-platform and xblocks-contrib.

[irtazaakram]

How do you suggest we handle this flag? https://github.com/openedx/xblocks-contrib/blob/problemblock/xblocks_contrib/problem/capa/xqueue_interface.py#L31:L45

https://github.com/openedx/edx-toggles?

[kdmccormick]

In edx-platform, ProblemBlocks are compatible with two types of runtimes:

1. the ModuleStoreRuntimes, which are based on ModuleStore and ContentStore and use MongoDB.
2. the LearningCoreXBlockRuntime, which are based on LearningCore and use MySQL.

The underlying system (ModuleStore vs LearningCore) is an implementation detail which the ProblemBlock does not know about. So, these details do not belong in xblocks-contrib. The entire contentstore/ directory should remain in edx-platform, and ProblemBlock tests should run without MongoDB.

If there are any tests that absolutely require MongoDB and contentstore, let me know. We will either need to leave those behind in edx-platform, or we will need to refactor them to be backend-agnostic.

[irtazaakram]

yes, these were only moved for testing. I've now removed contentstore/, and mongodb tests from this. I'll updated the PR once changes in edx-platform are merged so we can better see the changes.
Thank you for looking into this.

[farhan]

@openedx/axim-aximprovements @ttqureshi FYI, good architectural insights.
Takeaway: XBlock tests should run without MongoDB.

@kdmccormick It should be applied for all the XBlocks, right?
Please confirm: All the Extracted XBlock tests within edx-platform or moved to xblocks-contrib should run without MongoDB?

[kdmccormick]

@farhan The tests moved to xblocks-contrib should run without MongoDB. If tests require MongoDB, they can be left behind in edx-platform.

In general, the fix is to stop using Math.random() for generating the session ID and instead use a cryptographically secure source of randomness, such as window.crypto.getRandomValues (or self.crypto / topWin.crypto) in the browser. We should keep the overall format the same—16 printable ASCII characters between ! and ~—so that existing consumers of __gwt_SessionID continue to work unchanged.

The best way in this snippet is:

• Create a helper that fills the chars array using crypto.getRandomValues(new Uint8Array(16)), mapping each random byte into the desired range [ASCII_EXCLAMATION, ASCII_TILDE] without introducing significant bias for this non‑security‑critical formatting, or directly generating a random 16‑character string from random values.
• Prefer using the crypto object from the topWin/window where the session ID lives (for example, var cryptoObj = topWin.crypto || window.crypto;).
• Fall back to the existing Math.random() approach only if crypto is unavailable, to preserve behavior in very old browsers (still improving security where possible, and not breaking functionality).

Concretely, in xblocks_contrib/problem/assets/static/js/capa/genex/hosted.html:

• In the if (!topWin.__gwt_SessionID) { ... } block (lines 249–258), replace the for loop that uses Math.random() with code that:
  • Obtains a cryptoObj from topWin.crypto || window.crypto (if present).
  • If cryptoObj is present, uses cryptoObj.getRandomValues(new Uint8Array(16)) to generate 16 random values, then maps them into the printable ASCII range.
  • Otherwise, falls back to the existing Math.random() code.

No new external libraries are needed; window.crypto is a standard Web API.

In general, to fix insecure randomness you must replace uses of Math.random() (or similar weak PRNGs) in security‑sensitive contexts with a cryptographically secure source such as window.crypto.getRandomValues in browsers. When generating identifiers from random bytes, ensure you map bytes to characters without introducing bias that weakens security (or accept the minor bias if it is not critical).

Here, the only problematic use is the generation of topWin.__gwt_SessionID between lines 249–258. We can keep the same character range (! through ~) and length (16 characters), but instead of using Math.random() we should obtain random bytes via window.crypto.getRandomValues (or topWin.crypto.getRandomValues to align with the top window we’re storing the ID on) and derive character codes from those bytes. To minimize behavioral change, we’ll still produce characters in the ASCII 33–126 range by taking random bytes modulo the size of that range. The fix is entirely local to the if (!topWin.__gwt_SessionID) { ... } block: we’ll allocate a Uint8Array(16), fill it with secure random bytes, then map each random byte into the printable ASCII range and push the resulting codes into chars. No new external dependencies are needed, and no other parts of the file need modification.

In general, to fix unvalidated dynamic method calls you must validate the user-controlled key before using it to look up and invoke a function. That typically means: (1) reject keys that are not of the expected type/shape; (2) ensure the key refers to an own property of the map (not from the prototype chain); and (3) ensure the looked-up value is actually a function before calling it.

For this specific code, the best targeted fix is to harden the block that handles non-method messages (callbacks/responses) where s_transIds[i] is invoked. We can:

• Restrict i to a safe form (e.g., a string representation of a non‑negative integer or at least not equal to dangerous names like __proto__, constructor, prototype).
• Check that Object.prototype.hasOwnProperty.call(s_transIds, i) is true so we never call methods inherited via the prototype chain.
• Check typeof s_transIds[i] === 'function' before invoking it, to avoid TypeError.

These checks are all local to the s_onMessage handler and do not require changing how s_transIds is populated elsewhere in the file. The only code that needs modification is around line 349 in xblocks_contrib/problem/assets/static/js/capa/src/jschannel.js, within the else if (typeof i !== 'undefined') block. No extra imports are necessary; we will use Object.prototype.hasOwnProperty.call, which is a standard built-in.