Uusi salasana toimii selaimessa. Projekti A kääntyy. Projekti B palauttaa 407. Proxyn ei tarvitse valita satunnaisesti: yksi sen asiakkaista saattaa yhä esittää vanhaa tunnistetietoa.

Seuraa käyttäjiä, ei vain tiedostoja

Projektikohtainen ominaisuustiedosto voi poiketa käyttäjän oletuksesta. Ympäristöarvo voidaan kaapata, kun käynnistin käynnistyy. Tunnistetietojen apurilla voi olla oma tallennettu merkintänsä. Mitään niistä ei päivitetä vain siksi, että toinen sovellus hyväksyi uuden salasanan.

Tee lyhyt luettelo käyttäjistä, jotka todella käyttävät tiliä: interaktiiviset työkalut, build-palvelut, ajoitetut tehtävät ja sovellusasiakkaat. Kirjaa jokaisesta, mistä arvo tulee ja milloin se luetaan. Pidä itse arvo luettelon ulkopuolella.

Vertaa epäonnistunutta prosessia toimivaan

Tarkista tili, työhakemisto, valittu kokoonpano ja tunnistetietojen lähde. Kaksi samankaltaista riippuvuuksia käyttävää projektia voi käyttää eri paikallisia tiedostoja. Pitkään käynnissä oleva agentti voi säilyttää ennen kierron alkua saadun syötteen, vaikka uusi pääte näkisi päivitetyn ympäristön.

Käytä tarkoituksellista uudelleenkäynnistystä tai dokumentoitua kokoonpanon päivitystä vain siellä, missä kyseinen asiakas sitä tarvitsee. Kaiken uudelleenkäynnistäminen kerralla kätkee, mikä käyttäjä oli vanhentunut, ja voi keskeyttää asiaankuulumattoman työn.

Älä sekoita asiakkaan päivitystä mitätöintiin

Asiakkaiden päivittäminen ja vanhojen tunnistetietojen käyttökelvottomaksi tekeminen ovat erillisiä toimia. Proxyllä voi olla todennuksen välimuisti, ja muodostetulla yhteydellä voi olla erilainen elinkaari kuin salasanatiedostolla. Noudata operaattorin mitätöintikäytäntöä sen sijaan, että olettaisit yhden onnistuneen pyynnön todistavan vanhan tiliaineiston kadonneen.

Ota käyttäjäluettelo osaksi muutosta seuraavalla kierrolla. Onnistunut tulos on, että jokainen aiottu asiakas käyttää aiottua lähdettään ja tiliään, ei vain se, että salasanan valintaikkuna sulkeutui yhdellä työasemalla.

Aiheeseen liittyvät artikkelit