Er is om deze reden het principe van een meeting-registration-token geïntroduceerd. Voor elke aanmelding voor een bijeenkomst wordt een meeting-registration-token aangemaakt. Bij het annulerings token in bijvoorbeeld de bevestigingsmail wordt het meeting-registration-token als GET parameter meegegeven. Zodra men op die url klikt, wordt de GET parameter in de user setting opgeslagen van de ingelogde gebruiker. Bij andere url’s binnen het bijeenkomsten detail snippet ben/blijf je in dat geval de registrant, oftewel de deelnemer, van de aanmelding. Om zeker te weten welke aanmelding je bekijkt, is in het view formulier van je aanmelding de naam van de registrant, oftewel de deelnemer, terug te zien.

Wanneer je NIET bent ingelogd, kun je ALLEEN de aanmelding die gekoppeld is aan het meeting-registration-token annuleren. Binnen de context van het bijeenkomsten detail snippet ben je dus de registrant van de aanmelding, oftewel de deelnemer, daarbuiten ben je guest.

Wanneer je bent ingelogd kom je als de ingelogde gebruiker op de annuleringspagina van de bijeenkomst terecht. In het geval dat jij (met je eigen account) niet bent aangemeld voor die bijeenkomst krijg je de tekst "U bent niet aangemeld voor deze bijeenkomst" te zien. Wanneer jij (met je eigen account) wel bent aangemeld voor de betreffende bijeenkomst kun je de aanmelding annuleren die aan je eigen ingelogde gebruiker gekoppeld zit. Zowel binnen als buiten de context van het bijeenkomsten detail snippet ben je dus altijd jezelf.

Er is bewust voor gekozen om te werken met een meeting-registration-token in plaats van een autologin link. Het token zorgt ervoor dat ALLEEN de actie uitgevoerd kan worden waarvoor het token is aangemaakt. Dat betekent in dit geval, dat dit alleen werkt voor die specifieke aanmelding. Een autologin link geeft veel meer rechten dan nodig is en brengt mogelijke veiligheidsrisico's met zich mee.