Ir supervaizers un AP. supervaizers glabā loģiku un AP skatās savus klientus pēc MAC. Katram MAC ir flags - autentificēts vai nē. Loģika AP ir vienkārša - ja MAC ir autentificēts, visi pieprasījumi tiek sūtīti kur tiem pienākas. Pretējā gadījumā AP nomet visus misc pieprasījumus un visus HTTP pieprasījumus redirektē uz supervaizera domēnu. Šeit implementācijas atšķiras, daži lieto transparent proxy (draugiem.lv ends up in controller), daži rūteri atļauj trafiku konkrētiem domēniem=>IP adresēm un klients reāli tiek HTTP redirektēts uz supervaizera domēnu, kuram piekļuvi atļauj AP.
Supervaizers savukārt var būt jebkas - sākot no PHP skripta ar Facebook like, beidzot ar kerberu un aktīvo direktoriju un atrasties var kaut kur, dies zina kur. Kad lietotājs ir veiksmīgi izdarījis visu darāmo, supervaizers parasti fonā nosūta AP callback ar uz supervaizeru redirektotā klienta MAC un instrukciju Y (MAC uz supervaizeru parasti padod pats AP, piemēram POST/GET), pēc tam klientu redirektējot vai nu uz refresh, vai uz adresi, ko oriģināli ievadīja klients nākot no AP uz supervaizeru.
Supervaizeru, kā jau minēju var saprogrammēt praktiski jebko. Nu pilnīgi jebko. Lietotāju DB, reklāmas, FB laikus, statistikas vākt par konekcijām, whatever. Šādā veidā parasti setupo tādēļ, lai nebūtu konstanti mainot supervaizera loģiku jāmaina visiem AP softs un AP varētu turēt maksimāli vienkāršus gan harda, gan softa ziņā. A loģiku šādu AP keisā var uzprogrammēt diezgan elementāri kā OS izmantojot to pašu DD-WRT - viss, kas jādara ir jāglabā MAC adreses, supervienkāršs TCP/HTTP/whatever rows your boat serveris komunikācijai ar supervaizeru un jākontrolē konekti/diskonekti/taimauti klientiem, lai pēc laika atkal enforcētu reklāmu.
Vienkāršs home setups ko pats esmu ķimerējis ir DD-WRT powerēts atvērts TP-LINK AP's un neliels VPS apache/php kā supervaizers, kas prasa nomest SMS uz numuriņu lai saņemtu 24h pieeju pie juicy 100mb lane. Telekoms darbojas pēc tā paša principa ar bik modificētu loģiku un hardu. Kādreiz bija login ar kartiņām, tagad ir reklāma.
Ko tu gribi panākt? Izdzēšot parentu izdzēst arī childus? Ja tā, tad tas visvienkāršāk realizējams ar foreign key uz itemu kur parent_id ir foreign key uz tās pašas tabulas id ar null parent_id root elementam, on delete cascade vai ja tev ir kaut cik advancēts ORM (izskatās, ka nē) - ar modeļu on_delete eventu izdzēs chaildus caur modeļiem un tā līdz bezgalībai.
