Политика која дозвољава једну сесију по налогу изгледа решена све док не стигне друга пријава. Могућа су два исхода: новајлија замењује постојећу сесију или постојећа сесија задржава слот, а новајлија се одбија. Само је други исход политика у којој прва сесија побеђује. Клијентска опција којој прибегава већина укључује паралелност и зато то не даје.

Два уговора се крију иза једног подешавања

Када је паралелност искључена, друга веза са истим именом сертификата може истиснути сесију која већ ради. Укључивање паралелности дозвољава неколико сесија одједном, што је супротно ограничењу. Ниједно стање није политика одбијања, па одлука мора да се донесе сасвим на другом месту.

Запишите уговор пре него што било шта примените: коме се одбија, који доказ идентификује постојећу сесију и шта се дешава када сесија умре без чистог прекида. Политика коју нико није тако формулисао не може се касније тестирати.

Истискивање се дешава пре ваше куке за повезивање

На кодној путањи сервера 2.6 рана припрема новог клијента уклања постојеће примерке са истим именом када је паралелност искључена. То уклањање се дешава пре него што се покрене ланац руковалаца повезивањем. Зато скрипта која примети дупликат и врати грешку одбија новајлију пошто је постојећа сесија већ избачена - управо исход који је политика требало да спречи. Редослед повратних позива у upstream имплементацији једини је поуздан одговор за вашу градњу.

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

Анкетирање статусне датотеке такође није капија. Два покушаја која стигну заједно могу оба видети празан слот пре него што га иједан потврди, и оба настављају.

Преместите одлуку у аутентикацију

Управљачки интерфејс може преузети одлуку о аутентикацији после провере сертификата. У том распореду контролер није посматрач: прима сваки клијентски примерак који се повезује и одговара сме ли тај примерак да настави. Пошто одговор стиже пре успостављања, одбијање оставља постојећу сесију нетакнутом. Исти канал извештава о прекидима и тако контролер сазнаје да је слот законито ослобођен.

Сваки нови примерак мора проћи кроз ову капију, укључујући поновна повезивања и сваку путању која се поново аутентификује без питања. Капија до које неки примерци никада не стигну ништа не штити, а пропуст остаје невидљив док неко не проба заобилажење.

Токени могу проћи поред капије

Пошто се токен изда, сервер може да га валидира изнутра и да прескочи спољну аутентикацију за ту везу. Управљачки позив се никада не дешава, па провера слота имплементирана само тамо никада не види нови примерак. Такво понашање је погодност за кориснике и рупа за политику паралелности. Натерајте везе аутентификоване токеном да прођу еквивалентну ауторитативну проверу или искључите путању токена када политика захтева одлуку о свакој вези.

Не надокнађујте то безусловним прихватањем сваког токена. Истекао или невалидан токен ипак мора да не успе, и мора да не успе кроз исту тачку одлуке као и све остало.

Вежите резервацију за примерак, не за адресу

Адреса је слаб идентитет: поновно повезивање са истог преносног рачунара може доћи са друге адресе, а копирани акредитиви могу доћи са исте. Вежите резервацију за клијентски примерак који додељује сервер, да се поновна аутентикација већ прихваћеног примерка препозна као власник. Нови идентификатор примерка мора да добије свој слот кроз одлуку први побеђује, чак и када представља исти токен.

Ослободите само резервацију која припада неуспелом покушају. Одложени догађај прекида од старијег покушаја не сме да обрише слот новијег власника, зато ослобађање именује примерак, а не налог. После поновног покретања контролера усагласите живе сесије пре него што некога пустите, и примените исто правило на свакој капији која опслужује налог.

Одлучите одвојено како се обнавља заиста застарео слот. Администратору је потребан документован начин да га очисти, и та путања не треба да буде доступна кориснику који само кликне поново повежи.

Тестирајте парове који су важни: две скоро истовремене пријаве, поновно повезивање после чистог прекида, поновну аутентикацију постојеће сесије, одбијеног новајлију и поновно покретање контролера. У сваком случају постојећа сесија мора остати употребљива, а новајлија мора бити одбијен без колатералне штете за друге налоге.

Повезани чланци