Skip to main content
web-palvelu (login-register-moduuli) pyytää reCAPTCHA v2:ta (näkymätön) sähköpostikirjautumisessa, LDAP-kirjautumisessa, rekisteröitymisessä ja salasanan palautuksessa. Luo avain ja lue, mitä kukin asetus tekee, sivulta reCAPTCHA; tämä sivu vie sen Kubernetesiin.

Konfiguraatio

1

Sivustoavain ConfigMapiin

Sivustoavain on julkinen: jokainen kirjautumissivu näyttää sen.
2

Salainen avain ja laitehistorian avain Secretiin

Aseta molemmat avaimet yhdessä: jos sivustoavain on asetettu mutta salainen avain puuttuu, jokainen tarkistus epäonnistuu eikä kukaan voi kirjautua salasanalla, rekisteröityä tai palauttaa salasanaa. DEVICE_HISTORY_SECRET on oltava 64 heksadesimaalimerkkiä; kontti ei luo sitä.
3

Ota käyttöön ja käynnistä uudelleen

Tarkista sitten, että jokainen pod tavoittaa päätepisteen. Podit luovuttavat noin sekunnin jälkeen kullakin yhteysyrityksellä, ja kirjautuminen, jonka tarkistusta ei voida tehdä, epäonnistuu virheeseen:

Useita replikoita

Kaikkien replikoiden on jaettava DEVICE_HISTORY_SECRET, minkä ne tekevät, kun se on Secretissä. Eri arvoilla selain, joka läpäisi tarkistuksen yhdellä replikalla, saisi captchan uudelleen toisella. Nopeusrajoitukset lasketaan Redisissä kaikkien replikoiden yli.

Testattu Kubernetesissa

Googlen vahvistuspäätepisteen jäljitelmää vasten (johon luotettiin overleaf-certs-Secretistä tulevan NODE_EXTRA_CA_CERTS-asetuksen kautta) Kubernetes 1.37:ssä reCAPTCHAn päästä päähän -testimme menevät läpi (13 tapausta): yhdellä replikalla kirjautuminen, rekisteröityminen ja salasanan palautus kukin hylättynä ilman captchaa tai epäonnistuneella captchalla ja hyväksyttynä läpäistyllä captchalla, DEVICE_HISTORY_SECRET-avaimeen perustuva laitehistoria, jonka ansiosta selain voi ohittaa captchan, sekä CAPTCHA_TRUSTED_USERS; kolmella replikalla HAProxyn takana LDAP-kirjautuminen captchan kanssa.
Viimeksi muokattu 2. marraskuuta 2026