Chrome onAuthRequired: Check isProxy Before Sending Credentials

A browser extension can encounter authentication challenges from two different places: the proxy carrying the request and the destination website. They must not automatically receive the same account.

The useful discriminator in Chrome's webRequest.onAuthRequired event is isProxy. A callback that removes that check simply to make a prompt disappear may start supplying proxy credentials to an origin challenge.

Match the proxy you intend to trust

Checking isProxy is a start. Also constrain handling to the expected proxy challenger and request context. An extension managing several endpoints should select the account belonging to that endpoint, not a single global password for every challenge.

Do not assume that setting the proxy route and handling its login are one permission or one API call. Chrome documents them separately. Use the current webRequest reference for event data and authentication permissions. A Manifest V3 listener registration example shows synchronous registration and account selection inside the callback.

Check the manifest generation

Examples mentioning an experimental WebRequest API come from old extension releases. Current permission requirements depend on the extension's manifest generation and deployment model. In particular, authentication handling has its own supported permission path; an obsolete blocking listener example is not enough to establish that a Manifest V3 extension can run it unchanged.

A correct handler must also avoid retrying the same rejected credentials indefinitely. Treat a second challenge after a supplied account as evidence to investigate, rather than as a request to replay the password forever.

Credentials should stay in the extension's appropriate protected handling path. Do not publish them in a PAC file or hard-code them into a distributed sample. The goal is a narrowly scoped proxy login, not a browser-wide rule that answers every authentication challenge with the same secret.