Set Landing Page for Anonymous Access

1 Initial Problem

If Anonymous Access is activated, the user is always redirected to the public area in the repository when the installation is called up.

This behaviour has to be changed in the server configuration.

2 Conceptual Summary

When Anonymous Access is activated, you are offered to define a target that is displayed when the installation is called up. A default value for installation 'www.ilias-domain.de'.

The following options are offered via a selection in a radio:

1. LogIn Screen (if an SSO is addressed with this, the LogIn and the target defined for the user follow accordingly.)
2. Internal Resource (Adminstrators define a Reference ID. This includes a validation of whether the target can be accessed by anonymous users. The Target Resource is checked when the page is called up in the administration and when an entry is saved.)

(Side project: During implementation, the change to KS Forms is forced. It may be necessary to convert the input for domain filters: probably to a tag input).

3 User Interface Modifications

3.1 List of Affected Views

• LogIn-Screen
• Repository – somewhere

3.2 User Interface Details

Extended form in the administration

3.3 New User Interface Concepts

None

3.4 Accessibility Implications

None.

4 Technical Information

{ The maintainer has to provide necessary technical information, e.g. dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues. }

5 Privacy

Nothing specific.

6 Security

Nothing specific.

7 Contact

• Author of the Request: Samoila, Oliver [oliver.samoila]
• Maintainer: Seeland, Per Pascal [PerPascalSeeland] & Jansen, Michael [mjansen]
• Implementation of the feature is done by: {The maintainer must add the name of the implementing developer.}

8 Funding

If you are interest in funding this feature, please add your name and institution to this list.

• …

9 Discussion

Kergomard, Stephan [skergomard], 10 APR 2024: I don't think this is a good idea: We right now have a confusing state (I don't think it is fully cleaned up) with a state where we have no User and when we are presented with the User Anonymous. We also have Startingpoints that currently cannot be set for Anonymous (if I'm not mistaken, didn't check again, as this is all too confusing). We would now introduce a second place where the Startingpoints can be set and the interactions between the two are going to get muddy. We should really clarify the behaviour concerning users and then devise a consistent way of setting this. I also believe we should decide what we want: Either we have a User Aonymous or we have the setting for Anonymous Access (or we find an easy way to explain why we need the two and how they interact). I think the two have unclear interactions right now.

JourFixe, ILIAS [jourfixe], 15 APR 2024: Facing the different opinions about this feature suggestion we kindly ask the stakeholders of this request to discuss the concept of this implementation first and to come back to the JF with a common suggestion.

10 Implementation

{ The maintainer has to give a description of the final implementation and add screenshots if possible. }

Test Cases

Test cases completed at {date} by {user}

• {Test case number linked to Testrail} : {test case title}

Privacy

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

Approval

Approved at {date} by {user}.