adobe/aio-lib-state

Firewall restrictions are reported as bad credentials

Closed this issue ยท 12 comments

Expected Behaviour

When I use aio-lib-state from outside my company's firewall, Cosmos DB reports an error Request originated from client IP x.x.x.x This is blocked by your Cosmos DB account firewall settings. This circumstance should be somehow reflected in the exception returned from aio-lib-state.

Actual Behaviour

I'm getting an exception with message [StateLib:ERROR_BAD_CREDENTIALS] cannot access underlying DB provider. This gives the impression that the credentials are bad and leads me up the wrong track.

Reproduce Scenario (including but not limited to)

Outside company firewall that has access rules.

Steps to Reproduce

Run code locally that uses aio-lib-state.

Platform and Version

macOS 10.15.3, node v10.18.0

Sample Code that illustrates the problem

const stateLib = require('@adobe/aio-lib-state');
function main(params) {
  const state = await stateLib.init();
  const obj = await state.get('foo');
}

Logs taken while reproducing problem

Cause of issue is:

if (status === 403) logAndThrow(new codes.ERROR_BAD_CREDENTIALS({ messageValues: ['underlying DB provider'], sdkDetails: copyParams }))

which replaces the message about firewall forbidden access with the generic credentials message seen.

Thanks @dominique-pfister !
I am not sure whether we should specifically mention the DB type as we are abstracting storage and providing hooks for other implementations.

But agreed that the current error message is misleading and must be rephrased in this scenario.

Ideally, the different error types should also be explained in the repository documentation.

One improvement here could be adding a logger.debug on the error itself, so you can see it in the logs.

I am not sure whether we should specifically mention the DB type as we are abstracting storage and providing hooks for other implementations.

Of course, I'd rephrase the expected outcome that the error message should read:
[StateLib:ERROR_BAD_CREDENTIALS] cannot access underlying DB provider due to firewall rules

@shazron the state lib already logs the error, but this might be an addition to the underlying error sdk

@moritzraho I mean in _wrap, log the naked e there itself (before any conditionals), since for a 403 you are not logging that specifically

@moritzraho I mean in _wrap, log the naked e there itself (before any conditionals), since for a 403 you are not logging that specifically

Ah ok yes got you now, good point

@moritzraho could you have a look at it while we're working on the Files SDK?

@meryllblanchet sure, this relates to state, but there might be a similar issue in files

@moritzraho exactly, we should do it for both.

Fixed.