[ZEPPELIN-6366] Separate WebSocket max message size into a dedicated REST API

[seung-00]

What is this PR for?

Currently, configuration data is fetched through both REST API and WebSocket channels. However, the WebSocket path does not perform permission checks, and the only required data from it is the WebSocket max message size.

I extracted the websocket max message size field into a dedicated REST API, to improve security and simplify configuration handling.

What type of PR is it?

Improvement

Todos

• [ZEPPELIN-6312] Remove configuration WS usage in frontend #5060

What is the Jira issue?

• Open an issue on Jira https://issues.apache.org/jira/browse/ZEPPELIN/6366

How should this be tested?

• Check the configuration page (/configuration)
• Check the notebook page (/notebook/{notebook_id})

Screenshots (if appropriate)

Questions:

• Does the license files need to update? N
• Is there breaking changes for older versions? N
• Does this needs documentation? N

[Reamer]

I don't know if we should also adapt zeppelin-web? What do you think?

[tbonelee]

@Reamer Looks reasonable for zeppelin-web too. Are there specific concerns you’re considering, such as maintenance or behavior differences?

[tbonelee]

@seung-00
(If we also apply this to zeppelin-web.)
There is a failing test in zeppelin-integration(test-selenium-with-spark-module-for-spark-3-5 CI job).
After a quick note: in zeppelin-web's NoteImportCtrl, wsMaxMessageSize is called even when the user is not logged in.
The server then returns a 302 redirect to /api/login (shiro.loginUrl). When the login API responds with 405, the HTTP interceptor emits session_logout (

zeppelin/zeppelin-web/src/app/app.js

Line 170 in f1f6713

$rootScope.$broadcast('session_logout', data);

). The login controller listens for session_logout and programmatically clicks the login button (.nav-login-btn).
As a result, the login modal pops up immediately when the window opens, which is different from before, and the integration test fails.

It looks like we should change this to issue the API request only when the user is authenticated, or defer it until the moment it is actually needed.

[Reamer]

@Reamer Looks reasonable for zeppelin-web too. Are there specific concerns you’re considering, such as maintenance or behavior differences?

Yes both. All frontends should use the same interfaces. This makes it easier to remove things later on.

[seung-00]

@Reamer
In this case I applied it to both, as you mentioned, to make it easier to remove unreferenced things later on.
But I don’t think we need to do that for every task. Covering both sides would be a bit tricky, since the front-end codebases are quite different.

@tbonelee
I fixed the issue you mentioned.
If the CI failed due to the login modal, I think the CI job might need to be adjusted instead, because the wsMaxMessageSize API doesn’t require authentication.
However, I found that wsMaxMessageSize was being called and cached initially (same as before), but the field only needed in specific cases (e.g., exporting/importing note). So I modified it to be called only when required, now the CI error no longer occurs.

BTW, if the user isn’t logged in initially, showing the login modal seems more natural. 🤔

[tbonelee]

Everything seems right but the unused imports should be removed.

[tbonelee]

LGTM. I also agree with showing a login modal when authentication is required. Maybe we could address that in another issue.

[Reamer]

But I don’t think we need to do that for every task. Covering both sides would be a bit tricky, since the front-end codebases are quite different.

Sooner or later, we should send the old front end into well-deserved retirement. In my opinion, sooner rather than later.

[Reamer]

You have changed the path of the API class here. Probably so that the call is /api/wsMaxMessageSize. However, I also think /api/configurations/wsMaxMessageSize is very good and would prefer this API endpoint.

[seung-00]

@Reamer
I also think the path you mentioned looks good. However, since the authentication referenced in shiro.ini appears to be set up based on the /configuration path, I excluded /configurations from the path. The wsMaxMessageSize API is intended to be a non-authenticated API.

Please feel free to let me know if you have any other suggestions. 🤔