[MD] Data source with wrong password connection in index pattern

[kristenTian]

If a data source is created with wrong credentials, when user try to use it in index pattern creation. The current behavior will ask user to type in credentials (see screenshots).

However even type in correct ones there, it won't help with the connection. Tested with this data source http://54.70.243.216/app/management/opensearch-dashboards/dataSources/2c080040-37ba-11ed-9c7d-b99e8398c755 on index pattern creation.

The proposal is to change the prompt from asking for credentials to a user friendly error message.

[zengyan-amazon]

@zhongnansu can you take a look?

[kristenTian]

Please also test first create with wrong credential, then correct it using update data source, would it work in index pattern step.

[zhongnansu]

@zengyan-amazon @kristenTian

• to support Data source in index management, we use opensearch client instead of the original legacy client in indexpattern -> resolve_index.ts
  

  OpenSearch-Dashboards/src/plugins/index_pattern_management/server/routes/resolve_index.ts

  Lines 62 to 69 in 1dcf6fd

  	if (dataSourceId) {
  	const result = await (
  	await context.dataSource.opensearch.getClient(dataSourceId)
  	).indices.resolveIndex({
  	name: encodeURIComponent(req.params.query),
  	expand_wildcards: req.query.expand_wildcards,
  	});
  	return res.ok({ body: result.body });

• Then at router level, the 401 response from opensearch client is being added with a www-authenticate header, that causes the pop-up
  

  OpenSearch-Dashboards/src/core/server/http/router/router.ts

  Lines 329 to 333 in 1dcf6fd

  	return {
  	body: e.message,
  	headers: {
  	'www-authenticate': getAuthenticateHeaderValue(),
  	},

• The issue will still happen in index pattern if we use the original legacy client to resolve index, because if not explicitly specified wrap401Error=false, by default the legacy client adds this www-authenticate header to response header, by decorateNotAuthorizedError()

  OpenSearch-Dashboards/src/core/server/opensearch/legacy/cluster_client.ts

  Lines 92 to 97 in 1dcf6fd

  	} catch (err) {
  	if (!options.wrap401Errors || err.statusCode !== 401) {
  	throw err;
  	}
  	throw LegacyOpenSearchErrorHelpers.decorateNotAuthorizedError(err);

Proposed Solution

• 1. Considering we are adding support of legacy client for data source, after that, index pattern will switch back to use legacy client, then we can set the caller option at the service level, to pass in wrap401Error = false. It will not set WWW-Authenticate header anymore. Noticed this can only be done with legacy client, see 2) for why it wont work with new client.
• 2. While initiating client for datasource, see if we can have this wrap401Error configured, not likely with legacy client tho. But for new opensearch client, could be. This won't work because new client doesn't add the header, non can be configured ref
• 3. We catch the error for data source use case and cast to 400. Catching this error is not doable from data_source service level, can be done at the caller layer. Data_source service is only responsible for getting client. A client with incorrect credentials can still be initiated by data source service, and returned. We currently don't have logic in data source service to validate auth of client at creation time. 401 is thrown when the client is used by for example, index pattern to perform some action, like client.search().

Related Issue/PR #2204, #2133

Summary

I'll go with option 1, to update the #2204 to include the 401 specific change. fyi @zengyan-amazon

[kristenTian]

Thanks for great details, what does the service level exactly means in option 1? If you already implemented, could you please share some code example.

[zhongnansu]

Thanks for great details, what does the service level exactly means in option 1? If you already implemented, could you please share some code example.

In my PR, you can see wrap401Error = false was added as a default param in the callAPI. This is within the data source plugin. We don't need each caller to configure from their side. https://github.com/opensearch-project/OpenSearch-Dashboards/pull/2204/files#diff-442cda9a371f9aa2ce417631ddf7a8b80f9ec6ade15676b1cfe390f1c25b3fe7R109