Microsoft Entra Beteende för ID-uppdateringstoken

Om du använder anslutningsappen med uppdaterings-/åtkomsttoken för första part Microsoft Entra bör du observera att lösenordsändringar inte påverkar den befintliga anslutningen.

Storleksberäkning för filinnehållsparameter

Observera att filinnehåll som skickas till åtgärdskortsparametern kodas som en base64-sträng. Därför blir storleken på det nya filinnehållet upp till 30-40 procent större än det ursprungliga innehållet. Om någon begränsningsregel för innehållsstorlek tillämpats beaktas ny filinnehållsstorlek.

InvokerConnectionOverrideFailed-fel

Om du får ett fel som liknar '{"error":{"code":"InvokerConnectionOverrideFailed","message":"Could not find any valid connection for connection reference name 'shared_office365' in APIM tokens header."}}'. Prova detta:

• Rensa webbläsarens cacheminne.
• Ta bort anslutningen och lägg sedan till den igen.

IP-adresser för Microsoft Entra ID-baserade anslutningar

När du skapar en anslutning till anslutningsapparna som stöder ID-baserad Microsoft Entra autentisering autentiseras användaren mot Microsoft Entra ID och sedan får vi token med enhets-ID-anspråket. Värdet för detta anspråk anges med IP-adressen, varifrån användaren autentiserar från. Enhets-ID-anspråket är inställt på den första inloggningen (även om det är enkel inloggning) och förblir sedan i anspråk. Om du uppdaterar token återställs inte det här anspråket. Vi lagrar det bara på ett säkert sätt tills vi behöver uppdatera det, när det händer ringer Microsoft Entra vi ID igen för att uppdatera det och det är vad den IP-adressen är (i ett nötskal kommer den inte från kontakten i det här fallet, den kommer från användarens offentliga adress). Så den IP-adress som används av användaren när de loggar in på anslutningen (antingen automatiskt eller för hand) är deras offentliga IP-adress. Om det finns en lista över tillåtna IP-adresser konfigurerad i Microsoft Entra ID:t bör därför användarens IP-adress också tillåtas utöver de andra dokumenterade IP-adresserna.

OAuth Anslutningar kan inte delas

OAuth Anslutningar kan inte delas med andra användare på grund av säkerhetsskäl. Det kan exempelvis vara ett säkerhetsproblem om användare A kan använda ett anslutningsprogram som ägs av användare B för att utföra åtgärder som gör att det ser ut som att användare B har gjort åtgärden.

Sidnumreringssupport

Sidnumrering har implementerats i många åtgärdskort för anslutningar, som returnerar en uppsättning objekt : GetTen, GetItems, GetList o.s.v. Du kan använda den här funktionen genom att klicka på Inställningar på kortens menyalternativ:

Genom att aktivera sidnumrering fortsätter flödesmotorn anropa tjänsten tills den har samtliga objekt, alternativt når det "tröskelvärde" som du anger explicit i inställningarna:

Avsökningsutlösning

Om du stänger av flödet under en tidsperiod och aktiverar det på igen utlöses alla objekt under den perioden. Detta inträffar eftersom flödet Inaktivera/Aktivera inte återställer utlösartillståndet. Som en lösning tillhandahåller du utlösarparametern Filter Query för att filtrera bort oönskade objekt med hjälp av villkor med hjälp av olika fält, till exempel entitets-ID, skapat datum och uppdaterat datum. Om parametern Filter Query inte stöds kan du filtrera bort oönskade objekt med hjälp av åtgärdskort för flödesvillkor efter utlösaren.

Vidarebefordrade huvuden för klientbegäran

När du testar en anpassad anslutningsapp kan ytterligare rubriker som vidarebefordras av klienten (till exempel) Origin: https://make.powerautomate.com resultera i ett oväntat svar från serverdels-API:et. Kontrollera att alla rubriker vidarebefordras. Om du identifierar en klientrubrik i konflikt kan du ta bort eller åsidosätta den med hjälp av anpassade anslutningsprinciper.