Skip to content

Conversation

@cuzzlor
Copy link
Collaborator

@cuzzlor cuzzlor commented Nov 12, 2024

Problem

The prior behaviour of the http module was to log but continue when calling the provided authFactory function.

This results in some unexpected behaviour, since ignoring the failure would in the majority of cases cause the http request to fail, but it would be unclear to the caller clear why the http module is executing the request without the expected auth headers attached.

At least for us, this behaviour makes things more confusing, we expect any auth factory function failure to be the final stop in our code.

Proposed change

Since you would expect the authFactory function to run or fail if you provide one, change the behaviour to throw any error from the authFactory function after logging it.

Also

Address audit errors by updating all packages, including running the latest ts-toolkit init and adding 2 lint ignores for any

@cuzzlor cuzzlor requested a review from mderriey November 12, 2024 09:36
@cuzzlor cuzzlor force-pushed the change-http-on-auth-factory-error-throw branch from ab9f362 to 503bfa2 Compare November 12, 2024 10:01
Copy link
Member

@mderriey mderriey left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense to me, thanks Sam!

@cuzzlor cuzzlor merged commit 65cccbf into main Nov 13, 2024
2 checks passed
@mderriey mderriey deleted the change-http-on-auth-factory-error-throw branch November 13, 2024 09:00
authHeaders = authFactory ? await authFactory(requestContext as TContext) : {}
} catch (error) {
logger?.error('Authentication via authFactory failed', { error })
throw error
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will this cause a 401/403 type HTTP code?

Copy link
Collaborator Author

@cuzzlor cuzzlor Nov 14, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No - the point of my change is to prevent running the request if the auth factory function fails.

Previously the request would run anyway, without the result of the auth factory, and you'd end up with a confusing failed request which should never have started after the swallowed-and-logged auth factory error.

Essentially making for confusing AF behaviour getting an unauthorised response back because your auth factory failed, not getting your auth factory function error.

If your auth factory optionally adds auth headers, that's fine, just write the auth factory to do so.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants