Logto v1.40.0 brengt een tijdsbereik-kiezer voor auditlogs, rijkere webhookpayloads voor organisatieleden, grote prestatieverbeteringen voor grote organisaties en verschillende verbeteringen voor zelf-gehoste implementaties.
Logto v1.40.0 is een release gericht op het versterken van het platform. Deze versie maakt auditlogs schaalbaar en bruikbaar, laat precies zien wat er is veranderd in webhooks voor organisatieleden, versnelt organisatiequeries bij grote tenants, en verwijdert een aantal al lang bestaande pijnpunten voor zelf-gehoste deployments. Er zijn ook drie nieuwe connectoren toegevoegd. Dit is wat er nieuw is.
Auditlogs zijn vooral handig als er net iets is gebeurd — maar tot nu toe haalde de Console een onbegrensd venster op, wat traag werd bij tenants met grote hoeveelheden logs.
Deze release voegt een tijdsbereik-kiezer toe aan de auditlogspagina, standaard ingesteld op de afgelopen 7 dagen. Je krijgt vooraf ingestelde vensters (Laatste 1 uur, Laatste 24 uur, Laatste 7 dagen, Laatste 30 dagen) en een eigen datumrange. Oudere logs blijven bereikbaar door het venster simpelweg breder te maken (#8810).
Onder de motorkap heeft de Management API nu start_time en end_time queryparameters op GET /api/logs en GET /api/hooks/{id}/recent-logs (exclusieve grenzen in unix-milliseconds), zodat je logqueries ook programmatisch kunt afbakenen (#8806). Voor de aller-grootste tenants kort een nieuwe enableCap=true parameter de count-query af op ongeveer 10.000 rijen en stuurt een Total-Number-Is-Capped: true header mee, waarbij een exact totaal wordt ingewisseld voor een antwoord dat niet tegen de statement_timeout aanloopt; de Console schakelt over op een Vorige/Volgende-indeling wanneer de limiet wordt bereikt (#8796, #8802). Standaardgedrag zonder de parameter blijft ongewijzigd.
De Organization.Membership.Updated webhook gaf voorheen alleen aan dat het lidmaatschap was veranderd, maar niet wat er was veranderd. Nu bevatten payloads expliciete delta-velden — addedUserIds / removedUserIds en addedApplicationIds / removedApplicationIds — bij de endpoints voor lidmaatschap, plus addedUserIds bij uitnodigingsacceptatie en just-in-time-provisioning (email-domein en enterprise SSO JIT) (#8840).
Dit is volledig aanvullend en niet-breaking: lege deltavelden worden weggelaten, en elke array heeft een limiet van 5000 items voor bulkbewerkingen (gebruik GET /organizations/:id/users of .../applications om te reconciliëren als je daar overheen gaat). Zie de webhookreferentie voor het volledige contract. Dit werk vervangt een eerder communityvoorstel — dank aan @chiche84 (#8752).
Terwijl we toch in de sessiecode zaten, heeft GET /api/my-account/sessions nu ook een isCurrent-vlag op elk item, zodat beheerschermen voor sessies de rij "Dit apparaat" kunnen markeren en voorkomen dat de eigen sessie van de gebruiker wordt ingetrokken (#8731).
Verschillende wijzigingen richten zich op tenants met zeer grote organisaties:
GET /organizations/:id/users aggregeert nu rollen via een LATERAL subquery, zodat LIMIT de gebruikersset afkapt voordat de rollen worden opgehaald — in plaats van bij elke gepagineerde request de volledige members × roles join te materialiseren (#8826).organization_user_relations (tenant_id, user_id) die wordt gebruikt bij elke login en door de membership-middleware (#8818), en één op organization_role_user_relations (tenant_id, organization_id, user_id) die wordt gebruikt door getUserScopes en per-user role joins (#8819).PUT /organizations/:id/users schakelt over op een nieuwe delta-gebaseerde query die alleen de rijen schrijft die daadwerkelijk zijn veranderd, in plaats van elke membershiprij opnieuw te schrijven bij elke call — roltoewijzingen voor bestaande leden blijven behouden (#8820).prompt=none in plaats van direct naar het login-scherm te gaan, dankzij @taka-guevara (#8785).connectorId correct uit (#8758), en het label voor het aan/uitzetten van 2-stapsverificatie is duidelijker (#8792).Deze release voegt drie connectoren toe en verbetert er nog een aantal — deels vanuit de community:
auth mag nu user en pass weglaten, zodat relais die autoriseren op basis van bron (zoals IP/VLAN) werken zonder valse credentials (#8888).Een paar wijzigingen zijn specifiek gericht op soepelere OSS-deployments:
Afgeschermde admin-setup. De
installendb seedcommando's accepteren nu een--dapcflag (alias--disable-admin-pwned-password-check). Het initiële wachtwoordbeleid van de admin-tenant voert standaard een Have I Been Pwned-lekcheck uit, waarbij op elk admin-passwordapi.pwnedpasswords.comwordt aangeroepen — wat de eerste adminaanmelding laat hangen als dat endpoint niet bereikbaar is. Met--dapcwordt het beleid zonder deze lekcheck toegevoegd, dus voor het aanmelden van de admin is geen uitgaand netwerkverkeer meer verplicht. (Dank aan @darcyYe, #8859)
Admin-tekensleutels uit de database. OSS-deployments lezen nu de admin-tenant signing keys direct uit de database, waardoor de extra host/DNS-mapping wegvalt die de Logto-container eerder gebruikte om zijn eigen admin OIDC-configuratie via het externe endpoint op te halen (#8869).
Migratie vereist. v1.40.0 brengt databaseveranderingen mee (de nieuwe organisatie-relatie-indexen en extra interne kolommen). Trek na het updaten eerst de database-migratiestap, voordat je de server opstart. Zie de upgrade handleiding.
Klaar voor de upgrade? Bekijk onze upgrade handleiding voor stapsgewijze instructies.
Voor de complete lijst van wijzigingen, zie de GitHub releasepagina.
Vragen of feedback? Kom bij ons op Discord of open een issue op GitHub.