Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

User is spammed with login prompts on chrome #379

Closed
mmuzikar opened this issue Mar 12, 2024 · 10 comments
Closed

User is spammed with login prompts on chrome #379

mmuzikar opened this issue Mar 12, 2024 · 10 comments
Assignees
@phantomjinx
Milestone
2.0.0

Comments

@mmuzikar
Copy link
Contributor

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
Copy link
Member

@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
Copy link
Contributor Author

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
Copy link
Member

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
Copy link
Member

phantomjinx commented Mar 13, 2024 •
edited

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
Copy link
Member

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 phantomjinx self-assigned this Mar 14, 2024
@phantomjinx
Copy link
Member

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
Copy link
Member

@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
Copy link
Member

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

Screenshot_20240315_153043

phantomjinx added a commit to phantomjinx/hawtio-online that referenced this issue Mar 15, 2024
@phantomjinx
fix: Stops auth dialog popping up on Chrome (hawtio#379)
076c410 
* If a 401 http error is returned by jolokia/cluster then Chrome displays
  an authentication dialog, which is not required and disrupts the app. To
  stop the dialog appearing, the www-authentication header needs to be
  dropped from the http response.

* webpack.config.dev.js
 * In dev mode, adding the onProxyRes property to the proxy-middleware
   allows the www-authenticate header to be removed.

* nginx.js
 * In production mode, the response is already passed through the response
   function so detecting the status is 401, the www-authenticate header can
   be removed.
phantomjinx added a commit to phantomjinx/hawtio-online that referenced this issue Mar 15, 2024
@phantomjinx
fix: Stops auth dialog popping up on Chrome (hawtio#379)
57d90b6 
* If a 401 http error is returned by jolokia/cluster then Chrome displays
  an authentication dialog, which is not required and disrupts the app. To
  stop the dialog appearing, the www-authentication header needs to be
  dropped from the http response.

* webpack.config.dev.js
 * In dev mode, adding the onProxyRes property to the proxy-middleware
   allows the www-authenticate header to be removed.

* nginx.js
 * In production mode, the response is already passed through the response
   function so detecting the status is 401, the www-authenticate header can
   be removed.
tadayosi pushed a commit that referenced this issue Mar 18, 2024
@phantomjinx @tadayosi
fix: Stops auth dialog popping up on Chrome (#379)
257b29c 
* If a 401 http error is returned by jolokia/cluster then Chrome displays
  an authentication dialog, which is not required and disrupts the app. To
  stop the dialog appearing, the www-authentication header needs to be
  dropped from the http response.

* webpack.config.dev.js
 * In dev mode, adding the onProxyRes property to the proxy-middleware
   allows the www-authenticate header to be removed.

* nginx.js
 * In production mode, the response is already passed through the response
   function so detecting the status is 401, the www-authenticate header can
   be removed.
@tadayosi
Copy link
Member

tadayosi commented Mar 18, 2024 •
edited

@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 phantomjinx mentioned this issue Mar 18, 2024
Merged
@phantomjinx
Copy link
Member

Closing as fixed with #389

@lhein lhein added this to the 2.0.0 milestone Apr 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@phantomjinx phantomjinx

Labels
None yet
Projects
Kanban Board
Archived in project
Milestone
2.0.0
Development

No branches or pull requests
4 participants
@tadayosi @lhein @phantomjinx @mmuzikar