403-Forbidden ved dobbeltsignering & sletting av signaturer
Closed this issue · 6 comments
Konklusjon
Denne committen i Altinn.App.Core endrer oppførselen til reject
flow typer fra CompleteCurrentMoveToNext
til AbandonCurrentMoveToNext
.
Tilhørende sjekk i Altinn.Platform.Storage tar ikke med denne nye verdien i betrakningen, og derfor blir oppførselen ved action=reject
annerledes enn forventet.
Løsningen er å modifisere Altinn.Platform.Storage og LocalTest til å behandle verdien AbandonCurrentMoveToNext
slik den historisk har behandlet CompleteCurrentMoveToNext
.
Proposed fix:
Description of the bug
Rapportert via Slack
Jeg testet ut v8.2.1 nå for å teste ut dobbelsigneringen og sjekke at det signaturer ble slettet. Men etter at REVI (andre person som signerer) prøver å trykke reject, så kommer feilmeldingen opp:
fail: Altinn.App.Core.Infrastructure.Clients.Storage.InstanceClient[0] Unable to update instance process with instance id 500000/ec595b56-860f-40ae-bbff-d1f5fed49881 fail: Altinn.App.Api.Controllers.ProcessController[0] Platform exception when processing next. 403 - Forbidden -
Jeg har ikke gjort noen endringer i policy eller process siden sist oppdatering. Er det noen konfigurasjoner jeg mangler der?
Steps To Reproduce
- Klone ned https://altinn.studio/repos/krt/krt-1185a-1.git
- Endre pakkereferansen for
Altinn.App.Core
ogAltinn.App.Api
tilv8.2.1
- Endre pakkereferansen for
- Åpne skjema som Sophie Salt DDG Fitness (DAGL)
- Jeg legger ved en ferdig utfylt XML av skjema for å spare tid og lange spor
- Send inn skjema og velg "signer"
- I en annen fane, gå til localtest,
- Velg Gjentagende Forelder DDG Fitness (REVI) og trykk på "Refresh authentication"
- I første fane der man var Sophie Salt, refresh siden med F5.
- Nå skal man være innlogget som Gjentagende Forelder
- Trykk reject.
Additional Information
Vedlagt skjema XML:
<?xml version="1.0" encoding="utf-8"?>
<melding xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema" dataFormatProvider="SERES" dataFormatId="5792"
dataFormatVersion="45308">
<InnrapporterteData_KRT-1185>
<avstemming />
<revisor>
<navn>dfafa</navn>
<telefonnummerLandprefiks>47</telefonnummerLandprefiks>
<telefonnummer>12345678</telefonnummer>
<revisjonsselskap />
<revisorinformasjon>
<ansattRevisjonsselskap>false</ansattRevisjonsselskap>
<behandlerKlientmidler>false</behandlerKlientmidler>
</revisorinformasjon>
</revisor>
<revisorErklaeringForetakUtenKlientmidler>
<utenKlientmidler>true</utenKlientmidler>
</revisorErklaeringForetakUtenKlientmidler>
<revisorsUttalelse />
</InnrapporterteData_KRT-1185>
<Oppgave_KRT-1185>
<rapporteringsenhet>
<organisasjonsnummer>897069650</organisasjonsnummer>
<navn>DDG Fitness</navn>
<adresse>
<adresse>Sofies Gate 1</adresse>
<postnummer>0170</postnummer>
<poststed>Oslo</poststed>
</adresse>
<kontaktperson>
<navn>Sophie Salt</navn>
<telefonprefix>47</telefonprefix>
<telefonnummer>90001337</telefonnummer>
<epost>1337@altinnstudiotestusers.com</epost>
</kontaktperson>
</rapporteringsenhet>
<rapporteringsperiode>
<regnskapsaar>2018</regnskapsaar>
<periode>2</periode>
</rapporteringsperiode>
<infofelter>
<maalform>2068</maalform>
</infofelter>
</Oppgave_KRT-1185>
</melding>
Kan bekrefte at feilen er reproduserbar
Feilen løser seg ved å legge inn revisor med skrivetilgang i Task_1. Revisor-brukeren har kun lesetilgang, men det holder ikke tydligvis.
Så vidt jeg kan se fra Altinn.App.* og Altinn.Storage.* er ikke denne oppførselen et resultat av noen nye endringer... så da er neste spørsmål: Har denne appen faktisk fungert på version 8.x?
Feilen eksisterer ikke i Altinn.App.* v8.1.1
, så vi må komme til bunns i hvorfor oppførselen er endret mellom v8.1.1
og v8.2.1
.
Skjermbildet under viser at revisor har avslått signatur-steget og kommet tilbake til Task_1 med et varsel om at de ikke har skrive-tilgang. Denne delen fungerer ikke likt i v8.2.1 der man får en 403 feil ved oppdatering av prosessen, og instansen aldri blir satt tilbake til Task_1.
Oppdatert issue description med konklusjon av debugging.
Såvidt jeg kan se så vil dette kun påvirke actions av typen "reject" (processengine.cs):
FlowType = action is "reject"
? ProcessSequenceFlowType.AbandonCurrentMoveToNext.ToString()
: ProcessSequenceFlowType.CompleteCurrentMoveToNext.ToString(),
Eneste stedet jeg kan se at reject blir satt på action i frontend er read-sign-reject.json, men her er jeg på tynn is. Kanskje @bjorntore kan svare på hvorvidt denne endringen kan få uforutsette konsekvenser
Såvidt jeg kan se så vil dette kun påvirke actions av typen "reject" (processengine.cs):
FlowType = action is "reject" ? ProcessSequenceFlowType.AbandonCurrentMoveToNext.ToString() : ProcessSequenceFlowType.CompleteCurrentMoveToNext.ToString(),
Eneste stedet jeg kan se at reject blir satt på action i frontend er read-sign-reject.json, men her er jeg på tynn is. Kanskje @bjorntore kan svare på hvorvidt denne endringen kan få uforutsette konsekvenser
Riktig at det kun påvirker reject. Tror fiksen til Daniel blir bra.