401 login page and 403 page

[Atmire-Kristof]

References

Fixes #923

Description

This PR changes the redirectOn404Or401 (now called redirectOn4xx) operator to redirect the user to the login page when receiving a 401 and the user isn't logged in. It now also supports a redirect to a 403 page.

Instructions for Reviewers

How to test:

• Visit a restricted dso while logged out. Visiting the page should redirect you to the login page and after logging in, you should end up on the requested page.
• Visit a forbidden dso while logged in as a user that doesn't have any rights to view this dso. You should be redirected to a 403 page.

Checklist

This checklist provides a reminder of what we are going to look for when reviewing your PR. You need not complete this checklist prior to creating your PR (draft PRs are always welcome). If you are unsure about an item in the checklist, don't hesitate to ask. We're here to help!

• My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
• My PR passes TSLint validation using yarn run lint
• My PR doesn't introduce circular dependencies
• My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
• My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
• If my PR includes new, third-party dependencies (in package.json), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.

[tdonohue]

@Atmire-Kristof : Overall this looks great & it works as described. That said, I noticed a small oddity in the code of operators.ts (see inline comment below) which I'd like to get your feedback & @artlowel 's feedback on. It looks (to me) like we may no longer need the UnauthorizedComponent (at all), as it's only used in one place which seems impossible to trigger. Maybe I'm missing something here though.

In any case, I'm generally +1 on this PR. I'd just like you to look closer at the code to see if we should clean this up further and remove the UnauthorizedComponent.

[Atmire-Kristof]

As @tdonohue mentioned, it doesn't make sense for the operator to be able to redirect to a 401 page if not being logged in would redirect you to the login page regardless, so I've removed this check in the operator.
I also realised the feature-authorization guards use the 401 page when receiving a 401 from the REST API. I've modified this part to redirect to the login page instead if the user is not currently logged in, or the 403 page if they are (but unauthorised), for more consistency. This means the 401 page is now completely useless, so I've also removed it and every use of it entirely.

[tdonohue]

👍 Code looks good now, and I re-tested and it works as expected. Thanks @Atmire-Kristof !