Tutustu elokuun 2024 julkaisuumme, jossa on käyttäjän esittäytyminen, sovellussalaisuuksien hallinta, organisaatio- ja sovellustason sisäänkirjautumiskokemusbranointi ja paljon muuta.
Lisätty tuki käyttäjän esittäytymiselle Token Exchangen kautta:
POST /subject-tokens pyytää subject_token token exchange -käyttöön.POST /oidc/token päätepiste uudella grant-tyypillä urn:ietf:params:oauth:grant-type:token-exchange vaihtamaan subject_token käyttäjän esittäytymää varten access_token.-päätepisteeseen.Katso lisätietoja Käyttäjän esittäytyminen.
custom_dataLisätty uusi mielivaltainen objektikenttä custom_data sovelluksiin. Tämä kenttä voi tallentaa mitä tahansa lisätietoa, jota ei ole määritelty tavanomaisessa Application-skeemassa.
PATCH /api/applications/{applicationId}/custom-data päätepiste päivittää sovelluksen custom_data -kenttä.PATCH /api/applications/{applicationId} päätepiste mahdollistamaan custom_data -kentän ylikirjoittaminen.Lisätty uusi mukautettu datan JSON-editori sovelluksen yksityiskohtasivulle (paitsi suojatuille sovelluksille).
Turvalliset sovellukset (kone-kone, perinteinen web, suojatut) voivat nyt sisältää useita sovellussalaisuuksia vanhenemisajalla. Tämä mahdollistaa salaisuuksien kierrätyksen ja tarjoaa vieläkin turvallisemman kokemuksen.
Huomautus: Ennen tämän ominaisuuden luotu vanha salaisuus voi edelleen käyttää asiakastodennukseen. Kuitenkin on suositeltavaa poistaa vanhat ja luoda uusia salaisuuksia vanhenemisajalla parannetun tietoturvan vuoksi.
GET /api/applications/{applicationId}/secrets: Listaa kaikki sovelluksen salaisuudet.POST /api/applications/{applicationId}/secrets: Luo uusi salaisuus sovellukselle.DELETE /api/applications/{applicationId}/secrets/{name}: Poista sovelluksen salaisuus nimen perusteella.PATCH /api/applications/{applicationId}/secrets/{name}: Päivitä sovelluksen salaisuus nimen perusteella.DELETE /api/applications/{applicationId}/legacy-secret: Poista sovelluksen vanha salaisuus ja korvaa se uudella.Hallinnoidaksesi sovellussalaisuuksiasi, siirry Logto Konsoli -> Sovellukset -> Sovelluksen tiedot -> Päätepisteet ja Tunnistetiedot.
Alkuperäinen sovellussalauslukemuoto on nyt korvattu uudella salaisuushallintataululla. Tässä taulussa voit luoda, päivittää ja poistaa salaisuuksia.
Nyt voit asettaa vaaleita ja tummia logoja organisaatioille. Voit ladata logot organisaation asetussivulla.
On myös mahdollista ohittaa organisaation sisäänkirjautumiskokemuksen logo. Lisää vain organization_id parametri tunnistautumiskyselyyn. Useimmissa Logto SDK:ssa se voidaan tehdä käyttämällä extraParams -kenttää signIn -menetelmässä.
Esimerkiksi JavaScript SDK:ssa:
Arvo <organization-id> löytyy organisaation asetussivulla.
Jos et löydä extraParams kenttää käyttämäsi SDK:sta, ilmoita siitä meille.
Voit nyt asettaa logoja, faviconeita ja värejä sovelluksellesi. Näitä asetuksia käytetään sisäänkirjautumiskokemuksessa, kun sovellus aloittaa tunnistautumisprosessin. Jos sovelluksella ei ole brandausasetuksia, omni-sisäänkirjautumiskokemuksen brandaus käytetään.
Jos organization_id on annettu tunnistautumiskyselyssä, sovellustason brandausasetukset ohitetaan organisaation brandausasetuksilla, jos niitä on saatavilla.
Logto nyt injektoi sisäänkirjautumiskokemuksen asetukset ja lauseet index.html-tiedostoon paremman ensimmäisen näyttökerrraksen suorituskyvyn saavuttamiseksi. Kokemussovellus hakee edelleen asetukset ja lauseet palvelimelta, jos:
tsup liittimen pakettien rakentamiseen. Tämä nopeuttaa rakennusprosessia ja sen ei pitäisi vaikuttaa pakettien toimintaan.Vite @logto/console, @logto/demo-app ja @logto/experience pakettien transpilaatiota ja niputusta varten. Poista ParcelJS ja korvattu Vite:lla. Ei odotetä katkoksia.PATCH /api/applications/{applicationId}-päätepisteen jsonb-päivityskäyttäytyminenApplication-objektin kaikki jsonb-kentät tulee päivittää korvaa-tilassa yhdistä-tilan sijaan. Tämä muutos tekee PATCH-menetelmästä ennakoitavamman ja johdonmukaisemman RESTful API -suunnittelun kanssa.
yhdistä > korvaa PATCH /api/applications/{applicationId}-päätepisteessä.osittainen > täysi PATCH /api/applications/{applicationId}-päätepisteessä.oidc_client_metadata, custom_client_metadata, protected_app_metadata ja custom_data.Huomautus: Jos käytät Logto-konsolia päivittääksesi
Application-asetuksia, sinun ei pitäisi vaikuttaa tähän muutokseen. API-käyttäjät, jotka käyttävätPATCH-menetelmää päivittääkseenApplicationjsonb-kenttäasetukset, tulisi olla tietoisia tästä muutoksesta.PATCH-menetelmä korvaa nyt koko jsonb-kentän uudella syötetiedolla. Kaikki osittaiset syötetiedot vaikuttavista kentistä hylätään.
Vaikuttavat webhook-tapahtumat: Role.Scopes.Updated, Organizations.Membership.Updates.
API-vasteen tilakoodi, joka palautettiin webhook-tapahtumakuormituksesta, oli aina 404. Tämä johtui siitä, että webhook-tapahtumakuormitus lisättiin ennen kuin API-vasteen konteksti asetettiin.
Koska me vain laukaistaan webhook, kun tapahtuma on onnistuneesti käsitelty, tilakoodi pitäisi aina olla 2xx.
Tämä ongelma on korjattu siirtämällä webhook-tapahtumakuormituksen lisäys sen jälkeen, kun API-vasteen konteksti on asetettu.
Argon2d ja Argon2id. Käyttäjät, joilla on näitä algoritmeja, siirretään Argon2i:lle onnistuneen sisäänkirjautumisen yhteydessä.@logto/experience-selaimen listasetup-konfiguraatio on synkronoitu README.md:ssä mainittujen kanssa.