19/12/2011
I vores moderne verden er digital sundhed blevet lige så vigtig som vores fysiske velvære. Vores systemer, applikationer og online-konti er komplekse økosystemer, der, ligesom den menneskelige krop, kan udvise symptomer, når noget er galt. En sådan fejlmeddelelse, der kan forårsage stor frustration, er AADSTS900561. Ved første øjekast kan denne kode virke kryptisk og skræmmende, som en uforståelig medicinsk diagnose. Men frygt ej. I denne artikel vil vi agere som din digitale læge, dissekere dette problem, stille en klar diagnose og give dig en trin-for-trin behandlingsplan, så du kan genoprette dit systems sundhed og funktionalitet.

Forståelse af Symptomet: Hvad er AADSTS900561?
Når dit system viser fejlen "AADSTS900561: The endpoint only accepts POST requests. Received a GET request," er det et meget specifikt symptom. Forestil dig, at du forsøger at kommunikere med en person, men du bruger det forkerte sprog eller den forkerte gestus. Du rækker hånden frem til et håndtryk (en GET-anmodning), men den anden person forventer en bestemt adgangskode, der skal hviskes (en POST-anmodning). Resultatet er forvirring og en afvisning. Det er præcis, hvad der sker i den digitale verden. Dit system forsøger at hente information på en måde, som serveren eller slutpunktet ikke accepterer. Serveren er konfigureret til kun at modtage data via en sikker og specifik metode (POST), men modtager i stedet en åben anmodning om at få data (GET). Denne uoverensstemmelse i kommunikationsprotokollen er kernen i problemet og udløser alarmen i form af fejlkoden AADSTS900561.
Den Primære Diagnose: En Alvorlig Kommunikationsfejl
Diagnosen er klar: Der er en fundamental fejl i den autentificering- og kommunikationsprotokol, der anvendes. I medicinske termer er det som at sende en patient til den forkerte specialist. Hver specialist (endpoint) har sine egne procedurer og krav for at acceptere en patient. I dette tilfælde er "specialisten" (Microsofts autentificeringstjeneste) designet til kun at håndtere anmodninger, der kommer i et bestemt format (POST), som typisk indeholder følsomme oplysninger som brugernavn og adgangskode i selve anmodningens krop for øget sikkerhed. En GET-anmodning sender derimod ofte data i selve URL'en, hvilket er mindre sikkert og ikke acceptabelt for dette specifikke endpoint. Denne strenge regel er en sikkerhedsforanstaltning, der beskytter dine data. Fejlen er altså ikke et tegn på, at dit system er "døende", men snarere at det taler det forkerte sprog og skal korrigeres for at kunne kommunikere effektivt og sikkert.
Behandlingsplan: En Simpel Kur mod Fejlen
Heldigvis er behandlingen for denne digitale lidelse ofte ligetil og kræver ikke en større operation. Kuren handler om at opbygge tillid mellem dit system (din browser) og de nødvendige kommunikationspartnere (Microsofts login-tjenester). Ved at fortælle din browser, at disse specifikke adresser er sikre og betroede, tillader du en mere smidig og korrekt kommunikation. Nedenfor følger en detaljeret recept, som du kan følge.
Recept: Tilføjelse af Betroede Websteder i Google Chrome
- Åbn Indstillinger: Klik på de tre prikker øverst til højre i din Chrome-browser for at åbne menuen, og vælg derefter "Indstillinger".
- Naviger til Sikkerhed: I menuen til venstre skal du klikke på "Sikkerhed og privatliv" og derefter vælge "Websiteindstillinger".
- Find Indstillinger for Usikkert Indhold: Rul ned på siden og klik på "Yderligere indholdsindstillinger". Her finder du en mulighed, der hedder "Usikkert indhold".
- Tilføj de Nødvendige Adresser: Ved siden af "Må ikke vise usikkert indhold" skal du klikke på knappen "Tilføj". Et vindue vil poppe op.
- Indtast den Første Adresse: Indtast den første "betroede partner":
https://login.microsoftonline.comog klik på "Tilføj". - Indtast den Anden Adresse: Klik på "Tilføj" igen og indtast den anden nødvendige adresse:
https://autologon.microsoftazuread-sso.com/og klik på "Tilføj".
Når du har fulgt denne recept, har du etableret et tillidsforhold. Prøv at tilgå den side, hvor fejlen opstod, igen. I de fleste tilfælde vil symptomet være forsvundet, og dit system vil fungere som forventet.
Sammenligning af Kommunikationsmetoder
For at give et klarere billede af problemet, kan vi opstille en tabel, der sammenligner de to kommunikationsmetoder, der er involveret i denne fejl.
| Aspekt | GET-anmodning (Forkert Metode) | POST-anmodning (Korrekt Metode) |
|---|---|---|
| Formål | Anvendes til at anmode om og hente data fra en specificeret ressource. | Anvendes til at sende data til en server for at oprette eller opdatere en ressource. |
| Dataoverførsel | Data sendes som en del af URL'en og er synlige. | Data sendes i anmodningens krop (body) og er ikke synlige i URL'en. |
| Sikkerhed | Mindre sikker, da følsomme data kan blive eksponeret i browserhistorik, serverlogs osv. | Mere sikker, velegnet til at sende følsomme oplysninger som adgangskoder. |
| Resultat ved AADSTS900561 | Afvisning og fejlmeddelelse, da endpointet ikke accepterer denne metode. | Korrekt behandling og succesfuld autentificering. |
Når Førstehjælp Ikke Er Nok: Komplekse Syndromer
I nogle tilfælde kan den underliggende årsag til kommunikationsfejlen være mere kompleks. Dette er især relevant for systemudviklere. Her kan problemet ligge i selve systemets "DNA" – dets konfigurationsfiler. Et eksempel er manglen på et OperationId i en såkaldt `swagger.json`-fil. Man kan tænke på `OperationId` som et unikt CPR-nummer for hver specifik funktion i et system. Uden dette unikke ID kan andre systemer ikke præcist identificere og kalde den korrekte funktion, hvilket fører til fatale fejl under kodegenerering og integration. Dette er en dybere, mere strukturel sygdom, der kræver en specialists (udviklerens) indgriben for at rette op på systemets grundlæggende arkitektur. Behandlingen her er at gennemgå systemets definitioner og sikre, at hver operation har et klart og unikt `OperationId` tildelt.

Ofte Stillede Spørgsmål (OSS)
Hvad betyder AADSTS900561 i simple vendinger?
Det betyder, at dit system forsøger at tale med en server på en måde, serveren ikke forstår eller accepterer af sikkerhedsmæssige årsager. Du "spørger" (GET), når du burde "sende en forseglet pakke" (POST).
Er det farligt for mit system at have denne fejl?
Fejlen i sig selv er ikke farlig for dit systems integritet, men den forhindrer dig i at udføre en specifik handling, typisk at logge ind eller tilgå en beskyttet ressource. Det er et symptom på en funktionsfejl, ikke en virus eller et sikkerhedsbrud.
Hvorfor skal jeg tilføje sider til "betroede websteder"?
Ved at gøre dette fortæller du din browser, at den kan stole på kommunikationen med disse specifikke adresser. Dette kan løsne visse sikkerhedsrestriktioner, der utilsigtet blokerer for den korrekte kommunikations-protokol, og dermed løse problemet.
Hvad gør jeg, hvis denne løsning ikke virker?
Hvis den simple behandling ikke løser problemet, kan årsagen være mere kompleks. Det kan involvere netværksindstillinger, firewalls eller specifikke konfigurationer i den applikation, du bruger. I sådanne tilfælde, især i en arbejdssammenhæng, er det bedste skridt at kontakte din organisations IT-supportafdeling for yderligere assistance.
Hvad hvis jeg har mistet adgangen til min to-trins-verifikation?
Dette er et separat, men alvorligt problem. Hvis du har mistet den telefon, der er knyttet til din konto, skal du omgående kontakte din organisations IT-support. De har procedurer for at verificere din identitet på andre måder og kan hjælpe dig med at genvinde adgang til din konto.
Hvis du vil læse andre artikler, der ligner Digital Sundhed: Forstå og Behandl Fejl AADSTS900561, kan du besøge kategorien Sundhed.
