kosarko
commented
9 months ago @milanmajchrak with BE @ fb252cf576458e3cab4b054e4a3ee8b2fc5518bb the no_email (1.3.2.6) does not work. the FE shows some basic "can't send email" error; underneath it gets a 400 bad request from /api/autoregistration
the tomcat logs (cf. #1033 ) contain:
Oct 04 16:27:40 dspace-dev tomcat9[3422607]: Error parsing HTTP request header
Oct 04 16:27:40 dspace-dev tomcat9[3422607]: Note: further occurrences of HTTP request parsing errors will be logged at DEBUG level.
Oct 04 16:27:40 dspace-dev tomcat9[3422607]: java.lang.IllegalArgumentException: Invalid character found in the request target [/server/api/autoregistration?netid=no_email@ufal.hide.ms.mff.cuni.cz[https://ufal-point-dev.ufal.hide.ms.mff.cuni.cz/idp/shibboleth]&email=my_email@mff.cuni.cz ]. The valid characters are defined in RFC 723>Oct 04 16:27:40 dspace-dev tomcat9[3422607]: at org.apache.coyote.http11.Http11InputBuffer.parseRequestLine(Http11InputBuffer.java:494)
Oct 04 16:27:40 dspace-dev tomcat9[3422607]: at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:271)
Oct 04 16:27:40 dspace-dev tomcat9[3422607]: at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
Oct 04 16:27:40 dspace-dev tomcat9[3422607]: at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:889)
Oct 04 16:27:40 dspace-dev tomcat9[3422607]: at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1735)
Oct 04 16:27:40 dspace-dev tomcat9[3422607]: at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
Oct 04 16:27:40 dspace-dev tomcat9[3422607]: at org.apache.tomcat.util.threads.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1191)
Oct 04 16:27:40 dspace-dev tomcat9[3422607]: at org.apache.tomcat.util.threads.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:659)
Oct 04 16:27:40 dspace-dev tomcat9[3422607]: at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
Oct 04 16:27:40 dspace-dev tomcat9[3422607]: at java.base/java.lang.Thread.run(Thread.java:833)Is percent encoding (or base64?) of the params a solution?
I haven't tested the other use cases, yet.
The scenarios in this section test various header release policies by IDPs, in some cases they describe expected UI look. There are expectations on what needs to be configurable:
1.3.1. Testing discojuice
What we test here is that discojuice appears when expected, it looks ok and is configurable. For these tests the “master” source of the idp feed will be https://lindat.mff.cuni.cz/Shibboleth.sso/DiscoFeed (The actual url configured in discojuice might differ. Compare with how the current version uses https://lindat.mff.cuni.cz/repository/xmlui/discojuice/feeds?callback=dj_md_1). Currently, discojuice has a default configuration at https://lindat.mff.cuni.cz/aai/aai.js and local overrides in https://github.com/ufal/clarin-dspace/blob/clarin/dspace-xmlui/src/main/webapp/themes/UFAL/lib/js/aai_config.js. If this is different, this must be documented. E.g., how does one change the heading of the modal (currently “LINDAT/CLARIAH-CZ Repository”).
1.3.1.1. User initiated login
Users clicks the login button; a list of universities appears. If they have Unicode characters in their name or description (for example Chinese universities), these must be displayed correctly. The login button should always display the discojuice modal, it must not take the user to /login (or any other url).
1.3.1.2. System initiated login
When there’s no user logged in and this anonymous user tries to do an action that requires a login (accessing a restricted resource, going directly to “my submissions”, etc.), the system must ask him to log in. It should be using discojuice as well. As an example go to http://hdl.handle.net/11234/1-1664 (https://lindat.mff.cuni.cz/repository/xmlui/handle/11234/1-1664 ) and try downloading the file.
1.3.1.3. Local authentication
The list of IDPs shown by discojuice must contain a “Local authentication” option. This allows the user to use accounts local to the DSpace installation, i.e., no IDP is involved. This might redirect the user to some other url (in the repository space) such as /login. The method must accept correct credentials on the first attempt, i.e., CSRF tokens or other forms of protection must be used correctly.
1.3.2. Testing the log in process
The following test cases try to cover various attribute release policies, local authentication, logout, correct display of accents, etc. The “master” source of the idp feed will be Shibboleth.sso/DiscoFeed provided by the dockerized-idp-testbed sp (by default the url is https://localhost/Shibboleth.sso/DiscoFeed ). It is expected that after a successful login the user will be taken back to the page where the login was initiated. After a successful login the red “Login” button is replaced with a username that links to user’s profile and a logout button. Clicking logout signs the user out of the application (no need to chain sp logout nor idp logout). If a user is logged in for the first time a welcome page is displayed. This lists the attributes provided by the idp and links to a privacy policy page. It should be documented how to change the linked page. The shibboleth default.auth.group will be configured to “Authenticated”. This group will be created before the tests. All successful shibboleth logins (the users) must be assigned to that group. The header names exposed by the sp will match the old configuration
In v5 every user belongs to the Anonymous group. Logging in must not reduce what a user can see or do. The test system will have a valid smtp configuration. That said, with mail.server.disabled = true, the system should log the message and the addresses it would mail to (see https://github.com/ufal/clarin-dspace/blob/8a6ba5c98547942d7115b74cf4978e0b29ca50e4/dspace-api/src/main/java/org/dspace/core/Email.java#L465-L484). This should allow to go through all the test cases even without a functional mail server. When the tests ending up in a successful login are run for the first time a new user account is created. When repeated the existing account should be found. The implementation should describe what happens when an email changes at the idp see 1.3.2.9.
1.3.2.1. Local authentication
Discojuice is invoked and local authentication is selected. The system has an administrator account created via the cli create-administrator. This is used to log in. This is not a shibboleth login, user profile should not contain the “Authenticated” group.
1.3.2.2. Shibboleth login with eppn header and email available
Invoke discojuice select idp1 (entityID=https://idptestbed/idp/shibboleth), on the idp login page use “bfu” as the username. Back in the repository the displayed user name should be “Franta Uživatel Běžný”, the accents should be displayed correctly. Visiting the user profile should show the “Authenticated” group. This should use the eppn header, i.e., the stored netid should contain bfu@example.org. V5 does modify the netid before storing it (see https://github.com/ufal/clarin-dspace/blob/8a6ba5c98547942d7115b74cf4978e0b29ca50e4/dspace-api/src/main/java/cz/cuni/mff/ufal/dspace/authenticate/shibboleth/ShibEPerson.java#L259). V7.5 should do the same, or the netids won’t match (when we migrate the production setup).
1.3.2.3. Shibboleth login with persistent-id header and email available
Use idp2 and “anon” as the username; the user should be logged in successfully, be in the “Authenticated” and “IDP2” groups (there’s no mapping for the unscoped-affiliation with value “student”), the netid column should be filled in.
1.3.2.4. Group mapping
Login using idp1 and username “person”. The user should be assigned to the following groups: Authenticated, MEMBER, STAFF, UFAL_MEMBER and CUNI_STAFF
1.3.2.5. Same email different idp
After performing the 1.3.2.2 case. Logout, https://localhost/Shibboleth.sso/Logout, https://localhost/idp/profile/Logout (or test in a private tab). Select idp2 and use the “bfu” username. This should not sign the user in but display an error message.
Sufficient details should be logged into dspace (authentication) logs as well.
1.3.2.6. No mail header
Use idp1 and “no_email” username. This exposes a netid header but there’s no mail header. The system must ask the user to fill his email. It must accept valid emails, especially those using the + sign (dspace+test@example.com). An email with a verification token/link will be sent to this address. Following the verification link should sign the user in and display the welcome login with idp information (released attributes). Logout Log in again using idp1 and “no_email” username. The email prompt should not be shown this time, the user should be registered right away.
1.3.2.7. Neither netid nor mail
Use idp2, username “no_netid_no_email”. This should fail with a message similar to these two (https://github.com/ufal/clarin-dspace/blob/8a6ba5c98547942d7115b74cf4978e0b29ca50e4/dspace-xmlui/src/main/webapp/themes/UFAL/lib/js/messages/messages.js#L31-L32).
1.3.2.8. No netid
Use idp2, username “no_netid”. This should succeed. The netid column should be null. A first login should create an eperson a second login should find that eperson just by email.
1.3.2.9. Email change (documentation)
Use idp1, “bfu” username to login. Change https://github.com/ufal/dockerized-idp-testbed/blob/c4305f9628230c107f4e4ba7477d3bd1f895e116/ldap/users.ldif#L16 and rebuild the idp -testbed. Use idp1, “bfu” username. Is the email updated or not?