User is spammed with login prompts on chrome

[mmuzikar]

When Hawtio Online is making requests to the different jolokia containers, the requests get blocked with 403, which prompts users to put in username and password on chrome. This makes Hawtio Online basically unusable on chrome.

It might be related to some endpoints serving the index.html content, for example /keycloak/enabled or /auth/config both serve the HTML which fails on JSON parsing.

[tadayosi]

@mmuzikar It could depend on the settings at the Jolokia containers side. Can you provide more info on your settings and if possible steps to reproduce the issue?

for example /keycloak/enabled or /auth/config both serve the HTML which fails on JSON parsing.

I believe it's not a issue. It's just that they are a probe request and failures are expected, but the Fetch API always writes erros to browser console and I couldn't find a way to suppress the negligible errors.

[mmuzikar]

I have the example app https://quay.io/repository/hawtio/hawtio-online-example-camel-springboot running on Openshift and running hawtio-online with yarn start:online and opening the website in Chrome. But the same behavior happens with hawtio-online normally running in the OCP cluster. I'm not aware of any changed settings.

[phantomjinx]

This is an issue in testing in dev-mode using yarn start:online. It can be worked around by disabling the authentication requirements of jolokia on the test app using the following env vars:

• AB_JOLOKIA_AUTH_OPENSHIFT: false
• AB_JOLOKIA_PASSWORD_RANDOM: false
• AB_JOLOKIA_OPTS: useSslClientAuthentication=false,protocol=https

We do point out in the README that this does need to be done.

[phantomjinx]

Looking at this in terms of #354, I am adding better error handling & messaging to the Discover component. However, I looked to see if there was a way to disable this chrome login dialog and there is no good solution. Suggestions tend to be:

1. On the server change the response to something other than 401
2. Modify the WWW-Authenticate header

It is the combination of these that chrome decides is the reason to display the dialog.

As a workaround, I am trying out an error count tracker for each pod which if it reaches a threshold will stop trying to probe the connection for changes. Not ideal but at least minimizes the number of dialogs to a more manageable number. However, this is only a workaround and not an ideal situation.

[tadayosi]

If it's on OpenShift, generally we don't need to disable Jolokia authentication and aren't even recommended to do so.

When Hawtio Online is making requests to the different jolokia containers, the requests get blocked with 403, which prompts users to put in username and password on chrome.

Hmm, if it happens only with the new Hawtio Online v2 but not with the old v1, it's possible that I failed to port some subtle error handling code from hawtio-integration to hawtio-next: https://github.com/hawtio/hawtio-integration/blob/deebfd1ea93bd6e0cfa5bf63b9d7e7768a8b6110/plugins/jvm/ts/jolokia/jolokiaService.ts#L241-L267 https://github.com/hawtio/hawtio-next/blob/0ed4f1f5c8ee575b7fabddec7f9d1b13236b30d5/packages/hawtio/src/plugins/shared/jolokia-service.ts#L308-L355

Just FYI, we've been also suffering a difficult issue of closed connection due to SSL handshake error on OpenShift: https://access.redhat.com/solutions/5751001 So far we couldn't detect the root cause of it. But users repeatedly report this issue saying they cannot connect to pods from Hawtio Online. Not sure if it's related to the current issue.

[phantomjinx]

So made some progress...

For Development Environment

It is possible to add a proxy-response interceptor to the webpack-dev-server proxy config. This allows us to receive the response from the /master cluster and when it has a 401 status code, delete the www-authenticate header. This stops the popup dialog in Chrome from displaying and allows the probing of the jolokia connections to continue in the background.

For Production Environment

Since we also intercept the proxy responses in the nginx server using the nginx.js functions, I believe it possible we can perform the same approach in removing the www-authenticate header if a 401 is encountered.

Have successfully implemented the Dev Environment so will be trying to implement the Production Environment.

[phantomjinx]

@tadayosi

In respect of your info regarding missing code, I think that is not the case. The management-service.ts is responsible for the popup dialogs and happens both on the mPod.probeJolokiaUrl and mPod.jolokia.search.

Whereas the jolokia implementation, you cite above, appears to redirect away (window.location ...), the management-service.ts cannot as this is acting as a poll for each jolokia service in the Discover component. Therefore, I think the intercepting and removing of the www-authenticate header is the only solution.

[phantomjinx]

Adding couple of lines to the nginx.js I am able to drop the www-authenticate header and stop the popup dialog appearing in Chrome.

Tested in a full install of hawtio-online in OpenShift by removing the hawtio-online-tls-proxying secret from the volume and mounting in the hawtio-online deployment resource.

Note: The reason that the one pod in the screenshot is connectable is because it has the jolokia authentication disabling env vars added to its deployment

[tadayosi]

@phantomjinx Looks great. The only feedback I can make is that perhaps we could display the error messages in a better way. Now the Discover view seems to be getting more cluttering. We can consider using PF Alert or Notification and place it in a better position. https://v4-archive.patternfly.org/v4/components/alert https://v4-archive.patternfly.org/v4/components/notification-drawer

Let's try to follow PF design guidelines as much as we can.

[phantomjinx]

Closing as fixed with https://github.com/hawtio/hawtio-online/pull/389