NIFI-13313: Remove old UI

[mcgilman]

NIFI-13313:

• Use nifi-web-frontend as the default UI hosted at /nifi no longer deploying nifi-web-ui.
• Adding logout complete page.
• Updating backend to redirect to new logout complete page.
• Remove nifi-web-ui module.
• Updating LICENSE and NOTICE files for dependencies that are no longer included.
• Removing unnecessary rat config.
• Updating README.
• Updating proxy config to mirror actual context path.

[exceptionfactory]

Great to see all the user interface work bringing things to this point!

Just one question regarding the logout URI. The most straightforward approach would be to highlight this as an expected breaking change, requiring reconfiguration on Identity Provider configurations for OIDC or SAML. An alternative would be an add a redirect at the Jetty Server level to preserve compatibility. Thoughts?

[joewitt]

guessing yall already on top of this based on discussion above but the build fails currently with

[ERROR] OidcLogoutSuccessHandlerTest.testOnLogoutSuccessRequestFoundEndSessionNotSupported:161 expected: <http://localhost:8080/nifi/#/logout-complete> but was: <http://localhost:8080/nifi/%23/logout-complete> [ERROR] OidcLogoutSuccessHandlerTest.testOnLogoutSuccessRequestFoundEndSessionSupportedTokenFound:212 expected: <http://localhost/end_session?id_token_hint=oidc-id-token&post_logout_redirect_uri=http://localhost:8080/nifi/#/logout-complete> but was: <http://localhost/end_session?id_token_hint=oidc-id-token&post_logout_redirect_uri=http://localhost:8080/nifi/%2523/logout-complete> [ERROR] OidcLogoutSuccessHandlerTest.testOnLogoutSuccessRequestFoundEndSessionSupportedTokenNotFound:177 expected: <http://localhost:8080/nifi/#/logout-complete> but was: <http://localhost:8080/nifi/%23/logout-complete> [ERROR] OidcLogoutSuccessHandlerTest.testOnLogoutSuccessRequestNotFound:146 expected: <http://localhost:8080/nifi/#/logout-complete> but was: <http://localhost:8080/nifi/%23/logout-complete> [ERROR] Saml2LogoutSuccessHandlerTest.testOnLogoutSuccessRequestFound:95 expected: <http://localhost:8080/nifi/#/logout-complete> but was: <http://localhost:8080/nifi/%23/logout-complete> [ERROR] Saml2LogoutSuccessHandlerTest.testOnLogoutSuccessRequestNotFound:79 expected: <http://localhost:8080/nifi/#/logout-complete> but was: <http://localhost:8080/nifi/%23/logout-complete>

[EndzeitBegins]

As far as I remember Angular recommends to use "HTML5 style" routing for several years already, here's an exempt from the documentation:

Almost all Angular projects should use the default HTML5 style. It produces URLs that are easier for users to understand and it preserves the option to do server-side rendering.

To my knowledge to get this to work properly, one has to set the baseHref accordingly when serving the index.html .
This does not have to be done at build time, but can be achieved during runtime as well.

One idea is to use a placeholder as baseHref and replace it whenever the index.html is served. An example of this approach is available on GitHub. There might be other approaches of course.

I think we should evaluate whether it makes sense to look into this now instead of at a later point in time.
I think changing the approach later might prove to be more difficult as it basically invalides any hash-based links saved by users (or they have to be mapped, requiring a long-time workaround).

Also this may avoid the need for a redirect regarding the mapping.

Interested in your thoughts on this.

[mcgilman]

Interested in your thoughts on this.

Thanks for your comments! In my experience there is too much coordination between the front and back end to use PathLocationStrategy with dynamic context paths. That said, I'm sure we can we could figure it out using the technique referenced (where the server transforms the page when served) or possibly another approach. HashLocationStrategy completely decouples these concerns as the front end route is never even sent to the server.

2.0.0-M3 is released with HashLocationStrategy in place and if there is any feedback regarding it we could certainly evaluate the alternative.

[rfellows]

This is exciting! The latest round of tweaks look good to me. Thanks @mcgilman.

I'm a 👍 on this once it comes out of draft mode.

However, if we are voting, I would be in favor of taking this out of draft mode sooner rather than later.

[joewitt]

just built and things are looking really good!

[terjekid]

Does it mean that SAML and OICD won't be supported anymore?

[mcgilman]

SAML and OICD are still supported. Previously there were Servlet filters which consumed these init params which handled this routing. However, in an effort to further decouple front end and back end we've removed these Servlet Filters here [1]. These init params should have been removed in [1] but they were overlooked. Currently there is nothing consuming these.

[1] #8843