Integrate with Opencast's Login View

[lkiesow]

The Opencast 2.x+ admin interface comes with a login view built-in. This means that on the admin node, the login process works somewhat like this:

• You access a resource that is protected (like /) but aren't authenticated to Opencast
• Spring security will redirect you to the login-page
  • Spring will remember the site you tried to access
• You log into Opencast
  • Spring will redirect you to the site you wanted to access
  • There are a few exceptions to this. The details I don't accurately remember, but they are along the lines of, you aren't redirected to any JSON or XML APIs and if you tried accessing / you are redirected to the admin interface instead.
• You are logged in and ready to work with Opencast

The problem is what happens if you try accessing a non-admin node like a worker? There is no admin interface and therefor no login view. Before 2.0 that was not a problem since the login page was part of the runtime-info-ui package which existed on all nodes.

As a short-term workaround, the Opencast developers copied runtime-info-ui to runtime-info-ui-ng which is the same module just without the login page. The -ng variant got deployed on the admin node, the other one on all other nodes. Additionally, the path of the pre 2.0 login form and the dashboard present on the non-admin nodes got adjusted so that the paths are identical to the admin interface.

The admin interface Picard has no login form. This is good because that means we can have one module on all nodes containing the login form. That can be mostly what is in runtime-info-ui for now. There are a few things we need to take care of, though:

• The paths of the login view in runtime-info-ui matches the 2.x admin interface. We can and should get rid of the admin-ng part.
• If no path is given, the user should be forwarded to the admin interface on the admin and to something else sensible on all other nodes
  • We should be able to detect if the admin interface module is present on the node in the Java code which takes care of the HTTP redirect
  • Instead of the dashboard currently on the non-admin nodes, we could just forward to the REST docs directly. There is nothing useful left on the dashboard anyway. That also means that we can remove the dashboard code from the runtime-info-ui module

Regardless of the login view and the runtime-info-ui module, we also need to make sure that users are redirected to the new admin interface after login.

---

The old dashboard on non-admin nodes which I would just remove:

[Arnei]

Thank you very much for the write-up. I got some possibly naive questions.

If someone is trying to access a non-admin node, why can we only redirect them to the admin node after they've logged in? Would it not be simpler to immediately redirect them to the admin node? ... Are they even redirected to the admin node?

If runtime-info-ui had a login page and existed on all nodes, what was the change in 2.0 that caused a problem? You said that there was no Admin UI and therefore no login view on non-admin nodes, but runtime-info-ui had a login view and was on all nodes?

What is the point of ´runtime-info-ui-ng? My best guess would be that people wanted to avoid accidentally using the login page from runtime-info-uiinstead of the login page fromadmin-ui-frontend`, but that doesn't seem much of an argument.

Nowadays runtime-info-ui and runtime-info-ui-ng seem to have more differences than one of them not having a login page. Do you know how their roles have changed?

I scimmed the git logs on the admin-ui-picard branch, looking for commits pertaining to login. It seems at some point there was an attempt to make a admin-ui-picard-login module, but that was scrapped. Do you perhaps know why, or can reasonably speculate as to why?

On non-admin nodes, when does a login-form appear, when the dashboard?

Less of a question, more of a note: If we want to use the runtime-info-ui login form everywhere, that login form likely needs some improvements. For example, unlike the admin-ui-frontend form it does not support localization.

[lkiesow]

Why is there a login component in the new interface?

Interesting. I've missed that. And that's not what Isabella told me. I have no idea if they build this at the end of if this is leftover code. Needs investigation… Maybe we don't need what I wrote above after all. Although it would still be nice to get rid of the 2.x workaround.

If someone is trying to access a non-admin node, why can we only redirect them to the admin node after they've logged in? Would it not be simpler to immediately redirect them to the admin node? ... Are they even redirected to the admin node?

If you log in on a worker. You are not redirected to the admin node. The worker has a web interface. Although the only thing really useful there is the REST docs for that server. That's why I recommended redirecting users there if they log in on e.g. a worker.

If runtime-info-ui had a login page and existed on all nodes, what was the change in 2.0 that caused a problem? You said that there was no Admin UI and therefore no login view on non-admin nodes, but runtime-info-ui had a login view and was on all nodes?

The problem was that the 2.x admin interface came with a login which then conflicted with the one in runtime-info-ui. That's why runtime-info-ui-ng was created as a stripped down version of the old module specifically for the admin node.

What is the point of ´runtime-info-ui-ng? My best guess would be that people wanted to avoid accidentally using the login page from runtime-info-uiinstead of the login page fromadmin-ui-frontend`, but that doesn't seem much of an argument.

Well… the new login page wasn't ugly had internationalization and iirc, people realized too late that logins on non admin nodes did not work any longer since it was already stripped from the admin node. At some point, the design got updated on the other nodes. But no one made the effort to properly integrate it again. So… let's call it historical reasons :D

Nowadays runtime-info-ui and runtime-info-ui-ng seem to have more differences than one of them not having a login page. Do you know how their roles have changed?

First, the pom.xml file of one of the modules contains some magic which copies over files from the other module when being built. That means, it looks far more different than it actually is.

Once built, both should contain the REST docs. But only the runtime-info-ui contains the login page and the dashboard.

I scimmed the git logs on the admin-ui-picard branch, looking for commits pertaining to login. It seems at some point there was an attempt to make a admin-ui-picard-login module, but that was scrapped. Do you perhaps know why, or can reasonably speculate as to why?

Probably to remove the workaround once and for all.

On non-admin nodes, when does a login-form appear, when the dashboard?

Before you log in, you get the login form. After you log in, you get the dashboard.

Less of a question, more of a note: If we want to use the runtime-info-ui login form everywhere, that login form likely needs some improvements. For example, unlike the admin-ui-frontend form it does not support localization.

Yes. And it's also angular based. But that's a mini project a dev could do if bored ;-)

[Arnei]

Thanks again, that cleared up much of my confusion.

One thing still has me wondering though. If (in out ideal future) we do not want to have the rest docs on the workers, but redirect to the rest docs on the admin node. Then could we also not have a login page on the workers, but redirect to the login page on the admin node? After all, does it matter whether the user logs in on the worker and then gets redirected to the admin node, or if the user gets redirected to the admin node directly and then logs in there?

I have barely any practical experience with implementing redirects, so I have no idea if this feasible ^^

[lkiesow]

Putting the docs on the admin will be very hard since the admin does not know what services run on the worker. But if you manage that, I don't think you really need a login page.

That is, unless you then want to log in to test an API on the worker.

Or you are on an engage node, you protected the engage UI and are then trying to log in there.

…in other words: You can't easily get rid of the login page

[Arnei]

Okay, so there are actually reasonable use-cases for serving stuff (i.e. the rest docs) on non-admin nodes. Unfortunate :')