• release

Logto produktuppdateringar

Logto v1.40.0 introducerar en tidsintervallväljare för granskningsloggar, rikare webhook-payloads för organisationsmedlemskap, stora prestandaförbättringar för stora organisationer, samt flera förbättringar för självhostad drift.

Yijun
Yijun
Developer

Sluta slösa veckor på användarautentisering
Lansera säkra appar snabbare med Logto. Integrera användarautentisering på några minuter och fokusera på din kärnprodukt.
Kom igång
Product screenshot

Logto v1.40.0 är en release för att stärka plattformen. Den gör granskningsloggar praktiska i stor skala, visar dig exakt vad som ändrats i webhooks för organisationsmedlemskap, snabbar upp organisationsförfrågningar hos stora hyresgäster, och tar bort några långvariga friktionspunkter för självhostade installationer. Tre nya kopplingar lanseras också. Här är vad som är nytt.

Granskningsloggar du faktiskt kan avgränsa

Granskningsloggar är som mest användbara när något just har hänt — men tills nu hämtade Konsolen ett obegränsat fönster, vilket blev långsamt på hyresgäster med mycket stora loggmängder.

Denna version lägger till en tidsintervallväljare på granskningsloggsidan, som standard på senaste 7 dagarna. Du får förinställda fönster (Senaste 1 timmen, Senaste 24 timmarna, Senaste 7 dagarna, Senaste 30 dagarna) och ett anpassat datumintervall, och äldre loggar är fortfarande tillgängliga genom att helt enkelt öka intervallet (#8810).

Under huven får Management API start_time och end_time som sökparametrar för GET /api/logs och GET /api/hooks/{id}/recent-logs (exklusiva gränser i unix-millisekunder), så du kan avgränsa loggförfrågningar även programmatiskt (#8806). För de allra största hyresgästerna finns nu en ny enableCap=true parameter som avbryter räkningen vid ~10 000 rader och returnerar en Total-Number-Is-Capped: true header, vilket byter ut ett exakt antal mot ett svar som inte riskerar statement_timeout; Konsolen faller då tillbaka till en Föregående/Nästa-layout när gränsen är nådd (#8796, #8802). Standardbeteende utan parameter är oförändrat.

Webhooks för organisationsmedlemskap berättar nu vad som ändrats

Webbhooken Organization.Membership.Updated brukade endast berätta att medlemskapet hade ändrats, men inte vad som ändrades. Den bär nu explicita delta-fält — addedUserIds / removedUserIds och addedApplicationIds / removedApplicationIds — över medlemskapsendpoints, samt addedUserIds vid inbjudningsaccept och just-in-time-provisionering (e-postdomän och enterprise SSO JIT) (#8840).

Detta är helt tillagt och bryter inget befintligt: tomma delta-fält utelämnas, och varje array är begränsad till 5000 poster vid bulkoperationer (stäm av via GET /organizations/:id/users eller .../applications om du överskrider detta). Se webhookreferensen för hela kontraktet. Detta ersätter ett tidigare community-förslag — tack till @chiche84 (#8752).

När vi ändå var i sessionskoden har GET /api/my-account/sessions också fått en isCurrent flagga på varje post, så UI:er för sessionshantering kan markera raden "Denna enhet" och undvika att återkalla den egna sessionen (#8731).

Organisationer som förblir snabba när de växer

Flera förändringar riktar sig mot hyresgäster med mycket stora organisationer:

  • GET /organizations/:id/users aggregerar nu roller via en LATERAL subfråga, så LIMIT beskär användarsetet innan rolluppslagningar sker — istället för att materialisera hela members × roles-joinen vid varje paginerad förfrågan (#8826).
  • Två nya sekundärindex snabbar upp omvända sökningar: ett på organization_user_relations (tenant_id, user_id), träffas vid varje inloggning och av medlemskaps-mellanvaran (#8818), och ett på organization_role_user_relations (tenant_id, organization_id, user_id), används av getUserScopes och rolljoinar per användare (#8819).
  • PUT /organizations/:id/users byter till en ny delta-baserad fråga som endast skriver de rader som faktiskt ändrats, istället för att skriva om varje medlemsrad vid varje anrop — och den bevarar rolltilldelningarna för medlemmar som finns kvar efter uppdateringen (#8820).

Account Center och inloggningsfixar

  • Godkännande av villkor vid inloggning-till-registrering. När avtalspolicyn är "kräv godkännande av kryssruta endast vid registrering," så kommer nu användare som loggar in med okänd e-post eller telefon och väljer "skapa ett nytt konto" att behöva godkänna villkoren innan kontot skapas — vilket matchar den dedikerade registrerings- och sociala/SSO-flödena (#8835).
  • Initial lösenordsuppsättning. Användare utan lösenord, e-post eller telefon kan nu sätta sitt första lösenord via Account API utan någon verifieringspost (#8746).
  • Tyst ominloggning. Vid ett användarinfo-fel — till exempel en föråldrad access token efter användarbyte i samma webbläsare — återautentiserar Account Center nu med prompt=none istället för att studsa till inloggningsskärmen, tack vare @taka-guevara (#8785).
  • Renare utloggning och sociala callbacks. Utgångna sessioner i Account Center omdirigerar nu utan att visa det manuella inloggningsfelet (#8830), sociala länkcallbacken läser nu connectorId korrekt (#8758), och etiketten för 2-stegsverifiering är tydligare (#8792).
  • i18n. Rättade den kinesiska översättningen av "Passkey" i MFA-uttryck, tack till @rotempasharel1 (#8870).

Nya och förbättrade kopplingar

Den här versionen lägger till tre kopplingar och förbättrar flera fler — många av dem från communityn:

  • MailJunky e-postkoppling för transaktionsautentisering, bidragit av @devadarshh (#8638).
  • SMSBao SMS-koppling för inhemsk SMS-verifiering, bidragit av @wintbiit (#8871).
  • Aliyun SMS autentiseringstjänst koppling, bidragit av @CertStone (#8385).
  • Aliyun Direct Mail stöder nu konfiguration av Direct Mail-regionen (#8892).
  • WeCom hämtar rikare användarprofildetaljer via ytterligare API-anrop, bidragit av @liyujun-dev (#8191).
  • SMTP auth kan nu utelämna user och pass, så reläer som autoriserar enligt källa (t.ex. IP/VLAN) fungerar utan förfalskade inloggningsuppgifter (#8888).
  • Connector Kit skärpte igenkänning av e-postvarumärkes-URL:er för att undvika falska positiva utslag på förkortningar med punkter, tack till @aayushbaluni (#8747).

För självhostade användare

Några förändringar riktade specifikt till OSS-installationer:

Luftgapad admin-setup. Kommandona install och db seed accepterar nu flaggan --dapc (alias --disable-admin-pwned-password-check). Admin-hyresgästens seedade lösenordspolicy aktiverar vanligtvis "Have I Been Pwned"-läckagekontroll som anropar api.pwnedpasswords.com vid varje adminlösenord — och hänger sig vid första adminsignering om endpointen ej kan nås. Om du lägger till --dapc seedas policyn med läckagekontroll avstängd, så adminregistrering kräver inte längre utgående nätverk. (Tack @darcyYe, #8859)

Admin-signaturnycklar från databasen. OSS-installationer läser nu admin-hyresgästens signeringsnycklar direkt från databasen, och tar bort behovet av extra host/DNS-mappningar som tidigare gjorde att Logto-containern kunde hämta sin egen OIDC-konfiguration från externt konfigurerad endpoint (#8869).

Migrering krävs. v1.40.0 innehåller förändringar i databasschemat (nya organisation-relationsindex och extra interna kolumner). Efter att ha hämtat senaste version, kör databasändringssteget innan du startar servern. Se uppgraderingsguiden.

Kom igång

Redo att uppgradera? Kolla in vår uppgraderingsguide för steg-för-steg-instruktioner.

För den kompletta listan med förändringar, se GitHub releasesidan.

Har du frågor eller feedback? Gå med oss på Discord eller skapa en issue på GitHub.