Electron 'login' event fires repeatedly after wrong credentials — how to stop the 401 retry loop

Answer to the question

When the app.on('login') handler supplies cached credentials that the server rejects, Electron fires the login event again for the same origin. The event carries no explicit “credentials were rejected” flag, so the only reliable indicator is that the event is being emitted a second time for the same origin while you have already called callback(). A per‑origin guard that skips preventDefault() on the second firing will stop the endless 401 loop and allow Chromium’s default dialog to appear.

Likely explanation

Electron keeps retrying the authentication challenge until a successful 2xx response is received. Because your handler always calls preventDefault() and provides the same stale credentials, the server keeps replying 401 and Electron keeps refiring login. There is no built‑in signal that the credentials were rejected, so you must detect the repeat challenge yourself.

Confirmed facts

• Electron 28+ does not expose a flag in the login event that indicates a failed credential attempt.
• Each login event includes an authInfo object with host, port, realm, scheme, and isProxy fields. These are stable for a given origin and can be used as a key.
• There is no dedicated session‑level hook that reports “the 401 you just answered was wrong.” The webRequest.onHeadersReceived listener can see 401 responses, but it cannot reliably link them to a particular login invocation.

Steps for this case

1. Before calling preventDefault() and callback(), verify that authInfo.host (and optionally authInfo.port and authInfo.realm) matches an allowlist of origins you are willing to auto‑authenticate.
2. Maintain a Map keyed by a string such as authInfo.host + ':' + authInfo.port + ':' + authInfo.realm that records whether you have already supplied credentials for the current challenge sequence.
3. If the key is not present, call event.preventDefault(), decrypt the cached credential with safeStorage.decryptString(), and invoke callback(username, password). Then store the key in the Map to mark that the first attempt has been made.
4. If the key is already present, skip preventDefault(); let Chromium show its default dialog. Immediately delete the encrypted credential from safeStorage and remove the key from the Map so that a future legitimate challenge will not be auto‑answered again.
5. Optionally, reset the key after a successful non‑401 response from that origin. You can observe this with session.webRequest.onCompleted filtered for the origin and a status code 200-399. After reset, a new challenge will trigger the guard again.
6. Use separate keys for proxy and server challenges by including authInfo.isProxy and authInfo.scheme in the key string. This prevents a proxy challenge from suppressing a legitimate server prompt.

Why the guard belongs in the login handler

Because the login event is the only place where you can decide whether to supply credentials or defer to the default dialog, placing the guard there is cleaner and avoids the overhead of global request listeners. The guard also provides an immediate, per‑origin context that is lost if you try to infer the failure from later 401 responses.

Missing diagnostic detail

Could you log the full authInfo object (host, port, realm, scheme, isProxy) for each login firing? That would confirm that the repeat challenge is indeed for the same origin and help fine‑tune the key used in the Map.