[Priyank-gouda678]

NodeSession._login() assigns the requested sudo id and then, when the API user's token is not active, calls reset() before logging the API user in. reset() clears sudoId, so the if (this.sudoId) check that follows is false, POST /login/{id} is never sent, and login(id) returns the API user's token. Every later call on that SDK then runs with the API3 credentials (normally an admin, since sudo needs that permission) while isSudo() reports false. It happens on the first login(id) of a fresh session and on any login(id) after the API user's token has expired, so a service that sudoes to scope calls to an end user's permissions gets admin-scoped results back. The Swift AuthSession._login() has the same ordering. The Kotlin, C# and Python sessions are not affected: Kotlin doesn't call reset() there, C# checks the sudoId argument, and Python keeps _sudo_id outside the API login.

The sudo id is now assigned after the API user login in both sessions. The new nodeSession.spec.ts covers a fresh login('5'): it fails before the change (only POST /api/4.0/login is sent) and passes after. The Swift change was checked with a mock transport: before, login("5") leaves isSudo() == false holding the API token; after, it sends POST /login/5 and holds the sudo token.

Developer Checklist ℹ️

• Make sure to open an issue as a bug/issue before writing your code! That way we can discuss the change, evaluate designs, and agree on the general idea
• Ensure the tests and linter pass
• Appropriate docs were updated (if necessary)

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[gemini-code-assist]

Code Review

This pull request fixes an issue in both the Node and Swift SDKs where the requested sudo ID was being cleared immediately after assignment because the assignment occurred before the reset() call. To resolve this, the assignment of sudoId has been moved to execute after reset(). Additionally, a new unit test suite has been added for NodeSession to verify the sudo login behavior. The review feedback suggests normalizing newId in nodeSession.ts before comparison to prevent redundant assignments, and enhancing the new unit test to explicitly assert the exact sequence and number of API requests made during the login process.

[gemini-code-assist]

Comparing newId (which can be undefined) directly with this.sudoId (which is initialized to '') results in a redundant assignment of '' to this.sudoId when no sudo ID is requested. We can avoid this by normalizing newId first and then performing the comparison.

Suggested change

	if (newId !== this.sudoId) {
	// Assign new requested sudo id after reset() above, which clears it
	this.sudoId = newId || '';
	}
	const targetSudoId = newId || '';
	if (targetSudoId !== this.sudoId) {
	// Assign new requested sudo id after reset() above, which clears it
	this.sudoId = targetSudoId;
	}

[gemini-code-assist]

To make the test more robust and explicitly verify the login sequence (first logging in the API user, then performing the sudo login), we should assert that request was called exactly twice and verify the second call specifically using toHaveBeenNthCalledWith.

Suggested change

	expect(request).toHaveBeenCalledWith(
	'POST',
	'/api/4.0/login/5',
	null,
	null,
	expect.any(Function),
	settings
	);
	expect(request).toHaveBeenCalledTimes(2);
	expect(request).toHaveBeenNthCalledWith(
	2,
	'POST',
	'/api/4.0/login/5',
	null,
	null,
	expect.any(Function),
	settings
	);