fix(frontpage): Don't bruteforce protect "undefined"

[nickvergessen]

It's a misbehaving bug in the frontend but we are yet unsure how it occures

🛠️ API Checklist

🏁 Checklist

• ⛑️ Tests (unit and/or integration) are included or not possible
• 📘 API documentation in docs/ has been updated or is not required
• 🔖 Capability is added or not needed

[nickvergessen]

/backport to stable29

[DorraJaouad]

we are yet unsure how it occures

switching between rooms too fast ?

[nickvergessen]

Well the problem is it's not an API call, but actually requesting the frontend endpoint index.php/call/undefined

[Antreesy]

index.php/call/undefined

Could we track it somehow? Do we know the method (GET, POST, PUT, DELETE) where it happens?

[nickvergessen]

I only see 3 technical options:

1. Dashboard:

   spreed/src/views/Dashboard.vue

   Lines 102 to 106 in f176008

   	callLink() {
   	return (conversation) => {
   	return generateUrl('call/' + conversation.token)
   	}
   	},

   but it was not accessed by the user today
2. Signaling:

   spreed/src/utils/signaling.js

   Line 315 in d89d6f2

   window.location = generateUrl('call/' + token)

   but the user did not join a call today
3. Talk Hash:

   spreed/src/App.vue

   Lines 412 to 416 in d89d6f2

   	if (this.isNextcloudTalkHashDirty) {
   	// Nextcloud Talk configuration changed, reload the page when changing configuration
   	window.location = generateUrl('call/' + to.params.token)
   	return
   	}

   But the hash was not changed 8 times today. There was an update last night, so that could be the main root cause, but then it should be once (per tab?) and even then I would not know why to.params.token would be empty

[DorraJaouad]

the frontend endpoint index.php/call/undefined

Maybe switching between rooms too fast leads to token === undefined . Because I see not found page rendered so token must be faulty.

[nickvergessen]

With fast changing the only thing I can reproduce is ending up on "room not found" index.php/apps/spreed/not-found but never on call/undefined

[nickvergessen]

Today's user confirmed they only worked in mostly the same room (also what I see in the logs), but toggled between shared attachments and the chat frequently to leave comments about it

[SystemKeeper]

Does the call always result in a „not-found“ page in talk? Do we know it comes from talk itself or could it be a notification with a wrong action or something?

[nickvergessen]

Does the call always result in a „not-found“ page in talk?

Well the conversation with the token undefined does not exist, so any follow up request should lead to that. But it's the frontpage, so it will just load the "home".

Do we know it comes from talk itself or could it be a notification with a wrong action or something?

Persons didn't report any clicking on notifications. They opened attachments from the chat and closed them again.
I can reproduce the access.log pattern with that description apart from the call/undefined