Test: Increase flexibility in specification of IP address restrictions

1 Initial Problem

With Test: Add IP Ranges as Access Constraint to Test Settings, 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, where a specific exam room might not have a specific coherent segment of IP addresses, but instead simply a set of IP addresses. 

2 Conceptual Summary

To fix this, we propose a rework of the existing Test: Add IP Ranges as Access Constraint to Test Settings feature in order to support the following:

Settings for individual IP addresses need to be reworked in order to only support one IP address or IP address block in CIDR-notation.

Sidenote: While all of the IP addresses in the examples are IPv4 for the sake of readability, we are also advocating for support of IPv6.

3 User Interface Modifications

3.1 List of Affected Views

3.2 User Interface Details

In the test settings, it would only be possible to add IP ranges (per name) that are defined in the ILIAS Administration (see Add page for globally defining IP ranges), single IP addresses, and IP addresses in CIDR-notation.It is no longer possible to define IP ranges in the test settings.

For client ranges (the setting is located at the participant tab), it would also only be possible to add IP ranges that are defined in the ILIAS Administration, one(!) single IP address, and IP addresses in CIDR-notation.It is no longer possible to define IP ranges in the client range prompt/modal!

The mockups are showing an IP range, a CIDR notation style, and a single IP address. As of the nature of a mockup, the styling could be changed during the implementation. Also, the IP range shown here, although it is shown as "192.168.178.1-192.168.178.161" this is only the label of the defined IP range from the administration. It is also possible to show "PC Pool 212" as the label of the range.

The views that will need to be modified are

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

The filter option operates exactly identical to the way it's currently handled with the "From"- or "To"-IP-range filters. When displaying defined IP ranges within the table, they are comma-separated.

In order to achieve this check from a technical standpoint, class.ilTestAccess.php will need to be modified. Instead of checking whether a given client IP address is within the preset range, it will be necessary 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 for more information.

3.3 New User Interface Concepts

None

3.4 Accessibility Implications

None, as far as we know off.

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

With this feature, a database migration will be necessary (as currently there are two columns, "ip_range_from" and "ip_range_to" in the database). This solution would require additional parsing however. In our current mockup, parsing would then encompass:

This would, however, require 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 would be trivial (create new column, merge values of old columns into one, separated by "-" (dash), drop old columns). Exports from prior ILIAS versions would also require additional support (effectively the same migration steps) when importing into a version with this feature implemented.

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.

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.

4.5 Contact

Author of this request: Meißner, Bastian [simple_oaktree]
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 planning to implement this (incl. Unit tests and suggestions for test cases). After discussing with the relevant authorities, funding will still be required for reviewing 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}.