Test: Increase flexibility in specification of IP address restrictions

1 Initial Problem

With Test: Add IP Ranges as Access Constraint to Test Settings (and Test: Revision of the Participant Tab using the new data table), we have the ability to restrict test access via IP ranges. While a very neat feature in and of itself, we find that simply restricting IP ranges based on a upper and lower bound can be restrictive or even incompatible with networking setups across different institutions. For example, a specific exam room might not be assigned a coherent segment of IP addresses, but instead simply a set of IP addresses.

2 Conceptual Summary

This feature request reworks the two areas where the Test uses IP address ranges (given by their start and end address, respectively). These have been introduced by Test: Add IP Ranges as Access Constraint to Test Settings (IP address ranges for accessing a test, for all participants; pull request 7150) and Test: Revision of the Participant Tab using the new data table (extension of single IP address to an IP address range, as a per-participant setting; pull request 8188). The changes made by this feature request to these existing implementations cause the following to be supported:

At the same time, this feature request removes the ability to specify IP address blocks by their first and last IP address in the Test. Existing data is migrated; importing a test from the previous ILIAS release is handled in a similar way.

* Per-participant IP-address-based access control settings are reworked to support no more than one (single) IP address. Other options may be used more than once.

IPv6 and IPv4 addresses are supported.

2.1 Non-goals and end of scope

This feature request is limited to the Test. Other parts of ILIAS that might be aware of or use IP addresses are not affected. In particular, the user profile may have a setting for the client IP address, which is tested during login if it is set; this functionality is not modified by this feature request.

2.2 Relation to other Feature Requests

This feature is complemented by and requires some functionality from Add page for globally defining IP ranges. It is assumed that both feature requests are delivered together.

3 User Interface Modifications

3.1 List of Affected Views

3.2 User Interface Details

In the Test settings, when the (already existing) limitation to IP addresses has been enabled, only the following may be added to the list of allowed client IP addresses (alone or in combination):

It is no longer possible to use IP ranges specified by their start and end address in the Test settings.

Participant-specific client IP address limiting, which is already available and is configured in the Participants tab, is changed in a similar way, with a minor, but important difference: the available IP address settings which can be added (alone or in combination) are:

With Participant IP Range settings, only one entry is permitted.

It is no longer possible to use IP ranges specified by their start and end address in the client range prompt/modal! Note in particular that the option to allow a single IP address may not be repeated, but may only be utilized once (in total, not per IP address) in the participant-specific client IP address allowlist.

The views that are modified by this feature are

The new input for IP ranges is implemented using the "Tag" input field. This allows for the specification of multiple IP ranges. Autocomplete is employed in order to suggest names of predefined IP ranges (see Add page for globally defining IP ranges).

The filter option operates exactly the same way than before with the "From" or "To" IP range filters.

The table displays the configured IP address limitation selections as a comma-separated list.

In order to achieve this check from a technical standpoint, class.ilTestAccess.php is modified. Instead of checking whether a given client IP address is within the preset range, the new implementation needs to iterate over every entry made in the settings process ("every tag") and check the client IP address against every option individually. See the current implementation of the IP access check and our variant (TODO: needs update to current version) for more information.

3.3 New User Interface Concepts

None.

3.4 Accessibility Implications

None, as far as we know of.

4 Additional Information

4.1 Involved Authorities

If this request is related to multiple components, please list both authorities for all related components.

4.2 Technical Aspects

Introduction of this feature requires a database migration (as currently there are two columns, "ip_range_from" and "ip_range_to" in the database). The new solution requires additional parsing, compared to the previous one. In our current mockup, parsing encompasses:

This requires iterating over all set IP range entries. We acknowledge the presence of performance implications with this, but do conclude them to be negligible (or minor at worst).

Implementing the necessary migration is trivial (create new column, merge values of old columns into one, separated by "-" (dash), drop old columns). The import functionality for the Test requires additional support (effectively the same migration steps) so that exports from the previous ILIAS release can be imported into the release with this feature implemented. (ILIAS only supports upgrades or imports from the directly preceding release.)

4.3 Privacy

This feature does not introduce any new privacy issues, as it merely expands upon the concepts previously introduced in Test: Add IP Ranges as Access Constraint to Test Settings and .

4.4 Security

This feature does not introduce any new security issues, as it merely expands upon the concepts previously introduced in Test: Add IP Ranges as Access Constraint to Test Settings and Test: Revision of the Participant Tab using the new data table.

4.5 Contact

Author of this request: Meißner, Bastian [bmeissner.ur]
This request was created in association with Roeser, Nico [nicoroeser].

Please contact the T&A authority if you plan add this to the JF agenda and/or if the PR needed to be reviewed: Strassner, Denis [dstrassner].

4.6 Funding

Funding status and funding parties are listed in the block 'Status of Feature' in the right column of this page.

If you are interested to give funding for this feature, please get into contact with the person mentioned above as 'Contact'.

The University of Regensburg is implementing this functionality (incl. unit tests, suggestions for TestRail test cases, and support for some languages). As per discussing with the relevant authorities, funding is required for review and integration of this feature upon completion.

5 Discussion

Kergomard, Stephan [skergomard], 25. FEB 2026: If I'm understanding my post correctly, I didn't write that. I wrote that the administration of the IP ranges is out of scope for the test. A test allows to administer questions, responses, and grading, but not IP ranges. The article already specifies that there might be other uses for this option which is another strong hint that this doesn't belong inside the Test. But this request is labeled as pertaining to the Test and I'm specifying that most of it doesn't and that thus there are actually two requests with different scopes inside this one.

Strassner, Denis [dstrassner], 21 MAY 2026: Please note that this feature will only be part of trunk if his partner's feature, Add page for globally defining IP ranges also approved through the JourFixe and merged to trunk before this feature. We have discussed this condition with Nico and Bastian, and they agreed upon this. 

6 Implementation

Feature has been implemented by {Please add related profile link of this person}

6.1 Description and Screenshots

{ Description of the final implementation and screenshots if possible. }

6.2 Test Cases

Test cases completed at {date} by {user}

6.3 Privacy

Information in privacy.md of component: updated at {date} by {user} | no change required

6.4 Approval

Approved at {date} by {user}.