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 address ranges. While a very neat feature in and of itself, we find that simply restricting by means of IP address 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 component 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 ranges directly in the Test/Participant settings. Existing data is migrated to utilize IP address definitions (see Add page for globally defining IP ranges), importing a test from a previous ILIAS release is be handled in a similar fashion.

IP range settings for individual participants will be reworked identically, however with the additional constraint that only up to one entry can be made.

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

Currently, the settings for an IP address range in a Test consist of two inputs (lowest and highest IP address with access). These will be replaced with a Tag input field. This input field will accept the following types of values:

Asynchronous autocomplete is employed in order to suggest names of so-called IP address definitions (see Add page for globally defining IP ranges).

The modal for defining Client IP ranges for individual participants will be modified identically to the test settings. However, only one entry (no matter the type) is permitted.

For both settings pages, it will no longer be possible to use IP address ranges specified by their start and end IP address.

The views that are modified by this feature are

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 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). We propose merging these entries into a new column, "ip_ranges". This solution requires additional parsing, compared to the previous one. In our current mockup, parsing encompasses:

At worst, this requires iterating over all available entries set in the database. While we acknowledge the potential performance limitation this introduces, we feel that this is negligible overall.

Implementation of the necessary migrations will be performed with Add page for globally defining IP ranges.

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 Test: Revision of the Participant Tab using the new data table.

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}.