Pravilo koje dopušta jednu sesiju po računu izgleda riješeno dok ne stigne druga prijava. Moguća su dva ishoda: novi korisnik zamjenjuje postojeću sesiju ili postojeća sesija zadržava mjesto, a novi se odbija. Samo je drugi ishod pravilo prve sesije. Klijentska opcija koju većina ljudi posegne za njom uključuje paralelnost i zato to ne daje.

Dva ugovora skrivaju se iza jedne postavke

Kad je paralelnost isključena, druga veza s istim imenom certifikata može istisnuti sesiju koja već radi. Uključivanje paralelnosti dopušta nekoliko sesija odjednom, što je suprotno od ograničenja. Nijedno stanje nije pravilo odbijanja, pa se odluka mora donijeti negdje sasvim drugdje.

Zapišite ugovor prije nego što išta implementirate: kome se odbija, koji dokazi identificiraju postojeću sesiju i što se događa kad sesija umre bez čistog prekida. Pravilo koje nitko nije tako formulirao ne može se kasnije testirati.

Istiskivanje se događa prije vaše kuke za povezivanje

U putanji koda poslužitelja 2.6 rana priprema za novog klijenta uklanja postojeće instance s istim imenom kad je paralelnost isključena. To uklanjanje događa se prije nego što se pokrene lanac rukovatelja povezivanjem. Skripta koja primijeti duplikat i vrati grešku zato odbija novog nakon što je postojeća sesija već izbačena - upravo ishod koji je pravilo trebalo spriječiti. Redoslijed povratnih poziva u upstream implementaciji jedini je pouzdan odgovor za vašu gradnju.

StageWho can still refuseEffect on the incumbent
Certificate checkServer trust configurationNone
Authentication decisionThe authentication controllerNone, because establishment has not run
Connect handlerA profile scriptAlready evicted in the same-name case
Post-establishmentStatus tooling, monitoringBoth sessions already exist or one is gone

Anketiranje datoteke statusa također nije vrata. Dva zahtjeva koji stignu zajedno mogu oba vidjeti prazno mjesto prije nego što ga ijedan zauzme i oba nastavljaju.

Premjestite odluku u autentikaciju

Upravljačko sučelje može preuzeti odluku o autentikaciji nakon provjere certifikata. U tom rasporedu kontroler nije nadzornik: prima svaku instancu klijenta koja se povezuje i odgovara smije li ta instanca nastaviti. Budući da odgovor stiže prije uspostavljanja, odbijanje ostavlja postojeću sesiju netaknutom. Isti kanal izvješćuje o prekidima i tako kontroler sazna da je mjesto legitimno oslobođeno.

Svaka nova instanca mora proći ta vrata, uključujući ponovne veze i svaki put koji se ponovno autentificira bez upita. Vrata do kojih neke instance nikad ne stignu ne štite ništa, a propust ostaje nevidljiv dok netko ne isproba zaobilaznicu.

Tokeni mogu proći pokraj vrata

Nakon što je token izdan, poslužitelj ga može interno provjeriti i preskočiti vanjsku autentikaciju za tu vezu. Upravljački poziv nikad se ne dogodi, pa provjera mjesta implementirana samo ondje nikad ne vidi novu instancu. Takvo ponašanje pogodnost je za korisnike, a rupa za pravilo paralelnosti. Neka veze autentificirane tokenom prođu ekvivalentnu mjerodavnu provjeru ili isključite putanju tokena kad pravilo zahtijeva odluku o svakoj vezi.

Ne kompenzirajte to prihvaćanjem svakog tokena bezuvjetno. Istekao ili nevaljan token ipak mora pasti i mora pasti kroz istu točku odluke kao i sve ostalo.

Vežite rezervaciju uz instancu, a ne uz adresu

Adresa je slaba identifikacija: ponovna veza s istog prijenosnika može doći s druge adrese, a kopirani podaci za prijavu mogu doći s iste. Vežite rezervaciju uz instancu klijenta koju poslužitelj dodijeli, da se ponovna autentikacija već dopuštene instance prepozna kao vlasnik. Novi identifikator instance mora dobiti svoje mjesto kroz odluku prvi pobjeđuje čak i kad predstavlja isti token.

Oslobodite samo rezervaciju koja pripada neuspjelom pokušaju. Odgođeni događaj prekida od starijeg pokušaja ne smije obrisati mjesto novijeg vlasnika, zato oslobađanje imenuje instancu, a ne račun. Nakon ponovnog pokretanja kontrolera uskladite žive sesije prije nego što ikoga pustite i primijenite isto pravilo na svakom pristupniku koji poslužuje račun.

Odlučite zasebno kako se doista zastarjelo mjesto oporavlja. Administratoru treba dokumentiran način da ga očisti, a taj put ne smije biti dostupan korisniku koji samo klikne ponovno povezivanje.

Testirajte parove koji su važni: dvije gotovo istodobne prijave, ponovnu vezu nakon čistog prekida, ponovnu autentikaciju postojeće sesije, odbijenog novog korisnika i ponovno pokretanje kontrolera. U svakom slučaju postojeća sesija mora ostati upotrebljiva, a novi se mora odbiti bez štete za druge račune.

Povezani članci