auth module - Intensive blocking

[Florian-2]

Hello,

I'm trying to use the Tidal Web SDK for the first time, more precisely the "@tidal-music/auth" module. Using the example available in the "/examples" folder (I use pnpm and Vite.js) and taking care to fill in my own "clientId" and "clientSecret", at login time I have to validate a captcha, which I do, then I get blocked for some reason I don't know.

import { finalizeLogin, init, initializeLogin, credentialsProvider, logout } from "@tidal-music/auth";

// In my application, this information is present, and it works well with Tidal's rest api.
const CLIENT_ID = "";
const CLIENT_SECRET = "";

window.addEventListener("load", () => {
	const form = document.getElementById("loginRedirectForm");
	const logoutButton = document.getElementById("logoutBtn");

	form?.addEventListener("submit", (event) => {
		submitHandler(event).catch((error) => console.error(error));
	});

	logoutButton?.addEventListener("click", () => {
		logout();
		window.location.reload();
		localStorage.clear();
	});

	loadHandler().catch((error) => console.error(error));
});

const submitHandler = async (event: SubmitEvent) => {
	event.preventDefault();

	await init({
		clientId: CLIENT_ID,
		clientSecret: CLIENT_SECRET,
		credentialsStorageKey: "tidal",
	});

	const loginUrl = await initializeLogin({ redirectUri: "http://localhost:5173/user.html" });

	window.open(loginUrl);
};

const loadHandler = async () => {
	const clientId = localStorage.getItem("clientId");
	const redirectUri = localStorage.getItem("redirectUri");
	const form = document.getElementById("loginRedirectForm")!;

	if (clientId && redirectUri) {
		form.style.display = "none";

		await init({
			clientId,
			clientSecret: CLIENT_SECRET,
			clientUniqueKey: "test",
			credentialsStorageKey: "loginRedirect",
		});

		if (window.location.search.length > 0) {
			await finalizeLogin(window.location.search);
			window.location.replace("/index.html");
		} else {
			await credentialsProvider.getCredentials();
		}
	}
};

[osmestad]

Hey, and thanks for reporting, one possible cause of this can be if you have the browser developer tools open while logging in, our captcha tool is sensitive to that. Hope that helps :-)

If not, we'd need your full IP address to look in the logs if there is more information on why you got blocked.

[Florian-2]

Hey, and thanks for reporting, one possible cause of this can be if you have the browser developer tools open while logging in, our captcha tool is sensitive to that. Hope that helps :-)

If not, we'd need your full IP address to look in the logs if there is more information on why you got blocked.

With or without open development tools, unfortunately the same problem remains.

IP : 87.90.207.72

[osmestad]

We will need to investigate some more, if we can tweak the rules here a bit, will hopefully know more next week :-)

[Florian-2]

We will need to investigate some more, if we can tweak the rules here a bit, will hopefully know more next week :-)

any news ?

[osmestad]

Sorry for the delay, we are still in discussions with our security partners on how we can best detect traffic like this (and separate it from the bot traffic we want to block). Hope to have better news soon!

[Florian-2]

Hello, still no news? Do you know what the problem is exactly?

[osmestad]

Hey, so the problem is that developer traffic can look suspiciously much like automated bot traffic to our bot-detection system. There is no quick solution to that, but we are looking into ways that should allow us to "allow-list" developers for limited periods of time.

In the meantime, if you try again now it might work better, as the blocking is only temporary. And please ensure you do not have the browser developer tools open while logging in, as that will block you :-)