[Website] Prevent Query API defaults from overriding login info provided by the Blueprint

[bgrgicak]

Motivation for the change, related issues

As reported in #2872 the Playground website will override the login step and shorthand when applying Query API overrides.

The default behavior of the Query API is to set the login shorthand to true, but the override doesn't check if the Blueprint already provides a login step or shorthand. This behavior results in the user being unable to use the login step and shorthand on the Playground website, except if they explicitly set ?login=no in the Query API.

This PR addresses the issue by checking if the Blueprint contains a login step or shorthand, and only applies the default login override if the Blueprint doesn't contain a login step and shorthand.

Testing Instructions (or ideally a Blueprint)

• Checkout this branch
• Open this Playground website link
• Once Playground loads you should be logged in as the Demo User

[Copilot]

Pull Request Overview

This PR prevents the login query parameter from overriding login configurations that are already defined in a blueprint. The change adds logic to check for existing login configurations before applying the query parameter default.

• Adds detection for existing login steps in the blueprint's steps array
• Adds detection for existing login shorthand in the blueprint object
• Only applies the login=true default when neither form of login is already present

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[adamziel]

This means explicitly specifying login=yes won't override the Blueprint value. Let's do it a bit differently and only override if the query parameter was explicitly provided.

[bgrgicak]

This means explicitly specifying login=yes won't override the Blueprint value. Let's do it a bit differently and only override if the query parameter was explicitly provided.

I implemented it in 5834f58, but I'm not sure that this is the best solution.

My concern is this scenario. The Blueprints says login as Demo and the Query API says login. I would expect that _login as Demo_ + _login_ = _login as Demo_, but now it results in _login as admin_.

[adamziel]

My concern is this scenario. The Blueprints says login as Demo and the Query API says login. I would expect that login as Demo + login = login as Demo, but now it results in login as admin.

?login=yes basically means "log me in as admin" so that's the expected behavior. ?login=no means "don't log me in". Lack of the ?login query parameter means "do whatever the Blueprint do". While I agree ?login=yes could potentially confuse someone reading it as "log me in, either as admin or as the user specified in the Blueprint", that particular complaint never came up.

[adamziel]

How about this?

Suggested change

	const shouldSetLoginToTrue = () => {
	/**
	* Allow the Query API to explicitly set login
	* if the login query param is provided.
	*/
	if (query.get('login') === 'no') {
	return false;
	}
	if (query.get('login') === 'yes') {
	return true;
	}
	/**
	* Set login to true by default in the Blueprint
	* only if it doesn't already contain a login step or shorthand.
	* Otherwise, the login provided by the blueprint would be overridden.
	*/
	if (
	blueprint.steps?.some(
	(step) =>
	step && typeof step === 'object' && step?.step === 'login'
	)
	) {
	return false;
	}
	if (blueprint.login !== undefined) {
	return false;
	}
	return true;
	};
	if (shouldSetLoginToTrue()) {
	blueprint.login = true;
	}
	// Override the `login` property if explicitly requested:
	if (query.get('login') === 'yes') {
	blueprint.login = true;
	} else if(query.get('login') === 'no') {
	blueprint.login = false;
	}