Hei!
Vi har nå utarbeidet en liste over saker basert på sist nav-ref møte og den eksisterende listen. Vi vil gjerne at dere ser over den og kommenterer dersom det er mangler eller andre problemer med listen før førstkommende fredag.
Når det er gjort tar vi en avstemning på sakene i listen.
NB: Ingen avgir stemmer nå.
Listen med saker finnes på https://nav.uninett.no/wiki/nav-ref:navref_121115_avstemning
Stjernene er et estimat på både tid og kompleksitet for oppgaven, der en stjerne er minst og tre stjerner er mest kompleks. Spørsmålstegn angir stor usikkerhet i estimatet.
mvh.
Hei og godt nyttår folkens!!
Veldig bra med en oppdatert avstemningsliste. En av de sakene jeg synes er viktig, står på listen allerede API: more flexible authorization and administration https://bugs.launchpad.net/nav/+bug/1531853
Dette tror jeg blir viktigere i tiden framover med fusjon/samarbeid av Høgskoler. Men kanskje saken trenger litt mer detaljer
"... Tokens must provide a more detailed authorization where having a token does not automatically give you access to all of the API. ..."
Jeg er ikke noe programmerer, så jeg må bare spørre. Vil dette gjelde bare API, eller de ulike tools på web-sidene I NAV også? Tar vi dette på e-post eller på neste møte?
Mvh, Peder
-----Opprinnelig melding----- Fra: nav-ref-request@uninett.no [mailto:nav-ref-request@uninett.no] På vegne av John Magne Bredal Sendt: ti, 12. januar 2016 08:44 Til: nav-ref@uninett.no Emne: [nav-ref] Godkjenning av saker for prioritering
Hei!
Vi har nå utarbeidet en liste over saker basert på sist nav-ref møte og den eksisterende listen. Vi vil gjerne at dere ser over den og kommenterer dersom det er mangler eller andre problemer med listen før førstkommende fredag.
Når det er gjort tar vi en avstemning på sakene i listen.
NB: Ingen avgir stemmer nå.
Listen med saker finnes på https://nav.uninett.no/wiki/nav-ref:navref_121115_avstemning
Stjernene er et estimat på både tid og kompleksitet for oppgaven, der en stjerne er minst og tre stjerner er mest kompleks. Spørsmålstegn angir stor usikkerhet i estimatet.
mvh.
-- John Magne Bredal john.m.bredal@uninett.no +4791897366
Abels gt. 5- Teknobyen NO-7465 Trondheim
On 12. jan. 2016 09:34, Peder Magne Sefland wrote:
Hei og godt nyttår folkens!!
Godt nyttår til deg også!
Veldig bra med en oppdatert avstemningsliste. En av de sakene jeg synes er viktig, står på listen allerede API: more flexible authorization and administration https://bugs.launchpad.net/nav/+bug/1531853
Dette tror jeg blir viktigere i tiden framover med fusjon/samarbeid av Høgskoler. Men kanskje saken trenger litt mer detaljer
"... Tokens must provide a more detailed authorization where having a token does not automatically give you access to all of the API. ..."
Jeg er ikke noe programmerer, så jeg må bare spørre. Vil dette gjelde bare API, eller de ulike tools på web-sidene I NAV også? Tar vi dette på e-post eller på neste møte?
Det er ikke helt klart hvordan dette skal gjennomføres, noe som reflekteres i antall stjerner oppgaven har.
tl;dr - Vil i første omgang antagelig gjelde bare API
Det som er litt av problemet med autorisasjon (på web-sidene) i dag er at den er stort sett basert på url-er. Når man først har tilgang på en side i NAV så har man tilgang på alle dataene der (unntakene her er status-siden og PortAdmin som har sine egne systemer). Antagelig bør det vurderes å også begrense _data_ basert på innlogget bruker sine rettigheter (som ikke finnes i dag). Dette er ikke en del av oppgaven.
Det er helt mulig å si at et token i første omgang bare skal begrenses på endpoint, det vil i praksis si url-basert. Dette er vesentlig enklere og mer realistisk å gjennomføre som et første steg. Så må evt. begrensning av data komme i ettertid som følge av en generell omskriving av hele autorisasjonssystemet til NAV.
Det at et token skal knyttes mot en bruker gjør at dette (api- og web-side autorisering) antagelig må ses i sammenheng. I tillegg kommer en del av dataene som vises frem i NAV allerede fra API-et, og denne andelen vil bare fortsette å vokse. Det å ha en løsning med autorisasjon basert på flere rettigheter enn url-er er noe som vi absolutt må se på fremover.
Skulle dette kanskje vært en sak på prioriteringslista?
Mvh, Peder
-----Opprinnelig melding----- Fra: nav-ref-request@uninett.no [mailto:nav-ref-request@uninett.no] På vegne av John Magne Bredal Sendt: ti, 12. januar 2016 08:44 Til: nav-ref@uninett.no Emne: [nav-ref] Godkjenning av saker for prioritering
Hei!
Vi har nå utarbeidet en liste over saker basert på sist nav-ref møte og den eksisterende listen. Vi vil gjerne at dere ser over den og kommenterer dersom det er mangler eller andre problemer med listen før førstkommende fredag.
Når det er gjort tar vi en avstemning på sakene i listen.
NB: Ingen avgir stemmer nå.
Listen med saker finnes på https://nav.uninett.no/wiki/nav-ref:navref_121115_avstemning
Stjernene er et estimat på både tid og kompleksitet for oppgaven, der en stjerne er minst og tre stjerner er mest kompleks. Spørsmålstegn angir stor usikkerhet i estimatet.
mvh.
-- John Magne Bredal john.m.bredal@uninett.no +4791897366
Abels gt. 5- Teknobyen NO-7465 Trondheim
-----Original Message----- From: nav-ref-request@uninett.no [mailto:nav-ref-request@uninett.no] On Behalf Of John Magne Bredal Sent: Tuesday, January 12, 2016 11:25 AM To: Peder Magne Sefland; nav-ref@uninett.no Subject: Re: [nav-ref] Godkjenning av saker for prioritering
On 12. jan. 2016 09:34, Peder Magne Sefland wrote:
Hei og godt nyttår folkens!!
Godt nyttår til deg også!
Hei igjen og godt nytt år ja.
Veldig bra med en oppdatert avstemningsliste. En av de sakene jeg synes er viktig, står på listen allerede API: more flexible authorization and administration https://bugs.launchpad.net/nav/+bug/1531853
Dette tror jeg blir viktigere i tiden framover med fusjon/samarbeid av
Høgskoler.
Men kanskje saken trenger litt mer detaljer
"... Tokens must provide a more detailed authorization where having a
token does
not automatically give you access to all of the API. ..."
Jeg er ikke noe programmerer, så jeg må bare spørre. Vil dette gjelde bare API, eller de ulike tools på web-sidene I NAV også? Tar vi dette på e-post eller på neste møte?
Det er ikke helt klart hvordan dette skal gjennomføres, noe som reflekteres i antall stjerner oppgaven har.
tl;dr - Vil i første omgang antagelig gjelde bare API
Det som er litt av problemet med autorisasjon (på web-sidene) i dag er at den er stort sett basert på url-er. Når man først har tilgang på en side i NAV så har man tilgang på alle dataene der (unntakene her er status-siden og PortAdmin som har sine egne systemer). Antagelig bør det vurderes å også begrense _data_ basert på innlogget bruker sine rettigheter (som ikke finnes i dag). Dette er ikke en del av oppgaven.
Det er helt mulig å si at et token i første omgang bare skal begrenses på endpoint, det vil i praksis si url-basert. Dette er vesentlig enklere og mer realistisk å gjennomføre som et første steg. Så må evt. begrensning av data komme i ettertid som følge av en generell omskriving av hele autorisasjonssystemet til NAV.
Det at et token skal knyttes mot en bruker gjør at dette (api- og web-side autorisering) antagelig må ses i sammenheng. I tillegg kommer en del av dataene som vises frem i NAV allerede fra API-et, og denne andelen vil bare fortsette å vokse. Det å ha en løsning med autorisasjon basert på flere rettigheter enn url-er er noe som vi absolutt må se på fremover.
Skulle dette kanskje vært en sak på prioriteringslista?
Jeg tror det er fornuftig at token knyttes til bruker og dermed arver rettighetene. Så om dette er en større jobb bør det vel få et eget punkt?
Forøvrig var det feil link på denne: LP#1493272
Mvh, Peder
-----Opprinnelig melding----- Fra: nav-ref-request@uninett.no [mailto:nav-ref-request@uninett.no] På vegne av John Magne Bredal Sendt: ti, 12. januar 2016 08:44 Til: nav-ref@uninett.no Emne: [nav-ref] Godkjenning av saker for prioritering
Hei!
Vi har nå utarbeidet en liste over saker basert på sist nav-ref møte og den eksisterende listen. Vi vil gjerne at dere ser over den og kommenterer dersom det er mangler eller andre problemer med listen
før
førstkommende fredag.
Når det er gjort tar vi en avstemning på sakene i listen.
NB: Ingen avgir stemmer nå.
Listen med saker finnes på https://nav.uninett.no/wiki/nav-ref:navref_121115_avstemning
Stjernene er et estimat på både tid og kompleksitet for oppgaven, der en stjerne er minst og tre stjerner er mest kompleks. Spørsmålstegn angir stor usikkerhet i estimatet.
mvh.
-- John Magne Bredal john.m.bredal@uninett.no +4791897366
Abels gt. 5- Teknobyen NO-7465 Trondheim
-- John Magne Bredal john.m.bredal@uninett.no +4791897366
Abels gt. 5- Teknobyen NO-7465 Trondheim
On 14. jan. 2016 11:26, Jan Sigurd Refvik wrote:
-----Original Message----- From: nav-ref-request@uninett.no [mailto:nav-ref-request@uninett.no] On Behalf Of John Magne Bredal Sent: Tuesday, January 12, 2016 11:25 AM To: Peder Magne Sefland; nav-ref@uninett.no Subject: Re: [nav-ref] Godkjenning av saker for prioritering
On 12. jan. 2016 09:34, Peder Magne Sefland wrote:
Hei og godt nyttår folkens!!
Godt nyttår til deg også!
Hei igjen og godt nytt år ja.
<snip>
Det at et token skal knyttes mot en bruker gjør at dette (api- og web-side autorisering) antagelig må ses i sammenheng. I tillegg kommer en del av dataene som vises frem i NAV allerede fra API-et, og denne andelen vil bare fortsette å vokse. Det å ha en løsning med autorisasjon basert på flere rettigheter enn url-er er noe som vi absolutt må se på fremover.
Skulle dette kanskje vært en sak på prioriteringslista?
Jeg tror det er fornuftig at token knyttes til bruker og dermed arver rettighetene.
Jeg og Morten diskuterte dette en del i går. For selve oppgaven angående API-et så har jeg skrevet en mer detaljert kravspec på https://bugs.launchpad.net/nav/+bug/1531853 . Resultatet av diskusjonen kan ses der, men i bunn og grunn så forenkler vi autorisasjonen for å kunne komme i gang med oppgaven.
Så om dette er en større jobb bør det vel få et eget punkt?
Det har vært snakk om dette før og det har blitt etterspurt konkrete krav, men jeg har en følelse av at NAV-utviklerne må komme med et forslag på implementasjon før det blir noe fart i sakene. Litt av problemet er at vi ikke helt vet hva dere ønsker. Er det et reelt ønske om å forbedre autorisasjonen i NAV? I så fall hva er det som ønskes å autorisere? Eksempler på ting som kan autoriseres er f.eks. tilgang til data, redigeringsmuligheter, tilgang til sider (gjøres i dag med url-er) og tilgang til funksjonalitet.
Forøvrig var det feil link på denne: LP#1493272
Fikset.
Jeg synes John-Magne og Morten har beskrevet token-behovet godt i Launchpad-saken. Jeg ser ingen grunn til at et token skal ha et "arve rettigheter"-forhold til en bruker (account). Det er gjerne automatikk/script som har behov for tokens, og de er (vanligvis) ikke knyttet til bruker.
Det jeg synes mangler i kravspecen er å ta høyde for skriving til databasen gjennom apiet. Selv om det ikke implementeres i første runde kan det jo være greit å tenke gjennom hvordan det skal håndteres på sikt.
Gro-Anita
-----Original Message----- From: nav-ref-request@uninett.no [mailto:nav-ref-request@uninett.no] On Behalf Of John Magne Bredal Sent: Thursday, January 14, 2016 11:48 AM To: Jan Sigurd Refvik j.s.refvik@usit.uio.no; nav-ref@uninett.no Subject: Re: [nav-ref] Godkjenning av saker for prioritering
On 14. jan. 2016 11:26, Jan Sigurd Refvik wrote:
-----Original Message----- From: nav-ref-request@uninett.no [mailto:nav-ref-request@uninett.no] On Behalf Of John Magne Bredal Sent: Tuesday, January 12, 2016 11:25 AM To: Peder Magne Sefland; nav-ref@uninett.no Subject: Re: [nav-ref] Godkjenning av saker for prioritering
On 12. jan. 2016 09:34, Peder Magne Sefland wrote:
Hei og godt nyttår folkens!!
Godt nyttår til deg også!
Hei igjen og godt nytt år ja.
<snip>
Det at et token skal knyttes mot en bruker gjør at dette (api- og web-side autorisering) antagelig må ses i sammenheng. I tillegg kommer en del av dataene som vises frem i NAV allerede fra API-et, og denne andelen vil bare fortsette å vokse. Det å ha en løsning med autorisasjon basert på flere rettigheter enn url-er er noe som vi absolutt må se på fremover.
Skulle dette kanskje vært en sak på prioriteringslista?
Jeg tror det er fornuftig at token knyttes til bruker og dermed arver
rettighetene.
Jeg og Morten diskuterte dette en del i går. For selve oppgaven angående API-et så har jeg skrevet en mer detaljert kravspec på https://bugs.launchpad.net/nav/+bug/1531853 . Resultatet av diskusjonen kan ses der, men i bunn og grunn så forenkler vi autorisasjonen for å kunne komme i gang med oppgaven.
Så om dette er en større jobb bør det vel få et eget punkt?
Det har vært snakk om dette før og det har blitt etterspurt konkrete krav, men jeg har en følelse av at NAV-utviklerne må komme med et forslag på implementasjon før det blir noe fart i sakene. Litt av problemet er at vi ikke helt vet hva dere ønsker. Er det et reelt ønske om å forbedre autorisasjonen i NAV? I så fall hva er det som ønskes å autorisere? Eksempler på ting som kan autoriseres er f.eks. tilgang til data, redigeringsmuligheter, tilgang til sider (gjøres i dag med url-er) og tilgang til funksjonalitet.
Forøvrig var det feil link på denne: LP#1493272
Fikset.
-- John Magne Bredal john.m.bredal@uninett.no +4791897366
Abels gt. 5- Teknobyen NO-7465 Trondheim
On 15. jan. 2016 13:19, Gro-Anita Hillestad Vindheim wrote:
Det jeg synes mangler i kravspecen er å ta høyde for skriving til databasen gjennom apiet. Selv om det ikke implementeres i første runde kan det jo være greit å tenke gjennom hvordan det skal håndteres på sikt.
Glemte å svare på denne. Det rammeverket vi bruker til å lage API-et støtter dette fint. Det er selvfølgelig litt "skumlere" å tillate mer enn bare lesing via API-et, men jeg vil tro en løsning der man kan sette flagg for CRUD (create, read, update, delete) per token så vil det løse problemet.
mvh
Kommentar til "Detect topology of unrouted VLANs"
Kan dette kombineres med å få statiske prefix på ruterne inn i NAV? Dette er et savn hos NTNU, ref "NAV som IPAM"-diskusjonen vi hadde i Oslo.
Gro-Anita
-----Original Message----- From: nav-ref-request@uninett.no [mailto:nav-ref-request@uninett.no] On Behalf Of John Magne Bredal Sent: Tuesday, January 12, 2016 8:44 AM To: nav-ref@uninett.no Subject: [nav-ref] Godkjenning av saker for prioritering
Hei!
Vi har nå utarbeidet en liste over saker basert på sist nav-ref møte og den eksisterende listen. Vi vil gjerne at dere ser over den og kommenterer dersom det er mangler eller andre problemer med listen før førstkommende fredag.
Når det er gjort tar vi en avstemning på sakene i listen.
NB: Ingen avgir stemmer nå.
Listen med saker finnes på https://nav.uninett.no/wiki/nav-ref:navref_121115_avstemning
Stjernene er et estimat på både tid og kompleksitet for oppgaven, der en stjerne er minst og tre stjerner er mest kompleks. Spørsmålstegn angir stor usikkerhet i estimatet.
mvh.
-- John Magne Bredal john.m.bredal@uninett.no +4791897366
Abels gt. 5- Teknobyen NO-7465 Trondheim
On Fri, 15 Jan 2016 12:22:37 +0000 Gro-Anita Hillestad Vindheim gro-anita.vindheim@ntnu.no wrote:
Kommentar til "Detect topology of unrouted VLANs"
Kan dette kombineres med å få statiske prefix på ruterne inn i NAV? Dette er et savn hos NTNU, ref "NAV som IPAM"-diskusjonen vi hadde i Oslo.
Statiske ruter ble vel stort sett tatt vekk fra NAV fordi det krevde full nedlasting av hele rutingtabeller, noe som ble enormt dyrt, i form av CPU-forbruk for mange rutere, samt tidsforbruk forøvrig.
Om noen har et forslag til en bedre måte å få tak i statiske ruter på, så gjerne for meg.
Skal sjekke med Knut-Helge :) Det er han som har aller mest lyst til å få inn de statiske rutene.
Gro-Anita
-----Original Message----- From: Morten Brekkevold [mailto:morten.brekkevold@uninett.no] Sent: Monday, January 18, 2016 2:35 PM To: Gro-Anita Hillestad Vindheim gro-anita.vindheim@ntnu.no Cc: nav-ref@uninett.no Subject: Re: [nav-ref] Godkjenning av saker for prioritering
On Fri, 15 Jan 2016 12:22:37 +0000 Gro-Anita Hillestad Vindheim <gro- anita.vindheim@ntnu.no> wrote:
Kommentar til "Detect topology of unrouted VLANs"
Kan dette kombineres med å få statiske prefix på ruterne inn i NAV? Dette er et savn hos NTNU, ref "NAV som IPAM"-diskusjonen vi hadde i Oslo.
Statiske ruter ble vel stort sett tatt vekk fra NAV fordi det krevde full nedlasting av hele rutingtabeller, noe som ble enormt dyrt, i form av CPU-forbruk for mange rutere, samt tidsforbruk forøvrig.
Om noen har et forslag til en bedre måte å få tak i statiske ruter på, så gjerne for meg.
-- Morten Brekkevold UNINETT
Hei,
Trenger denne jobben gå så ofte? For HiVolda, så tror jeg det hadde holdt 1 gang i uken.
Mvh, Peder
-----Opprinnelig melding----- Fra: nav-ref-request@uninett.no [mailto:nav-ref-request@uninett.no] På vegne av Gro-Anita Hillestad Vindheim Sendt: ma, 18. januar 2016 14:45 Til: Morten Brekkevold morten.brekkevold@uninett.no Kopi: nav-ref@uninett.no Emne: RE: [nav-ref] Godkjenning av saker for prioritering
Skal sjekke med Knut-Helge :) Det er han som har aller mest lyst til å få inn de statiske rutene.
Gro-Anita
-----Original Message----- From: Morten Brekkevold [mailto:morten.brekkevold@uninett.no] Sent: Monday, January 18, 2016 2:35 PM To: Gro-Anita Hillestad Vindheim gro-anita.vindheim@ntnu.no Cc: nav-ref@uninett.no Subject: Re: [nav-ref] Godkjenning av saker for prioritering
On Fri, 15 Jan 2016 12:22:37 +0000 Gro-Anita Hillestad Vindheim <gro- anita.vindheim@ntnu.no> wrote:
Kommentar til "Detect topology of unrouted VLANs"
Kan dette kombineres med å få statiske prefix på ruterne inn i NAV? Dette er et savn hos NTNU, ref "NAV som IPAM"-diskusjonen vi hadde i
Oslo.
Statiske ruter ble vel stort sett tatt vekk fra NAV fordi det krevde full nedlasting av hele rutingtabeller, noe som ble enormt dyrt, i form av CPU-forbruk for mange rutere, samt tidsforbruk forøvrig.
Om noen har et forslag til en bedre måte å få tak i statiske ruter på, så gjerne for meg.
-- Morten Brekkevold UNINETT
On Mon, 18 Jan 2016 14:00:27 +0000 Peder Magne Sefland peder.sefland@hivolda.no wrote:
Trenger denne jobben gå så ofte?
Neppe.
For HiVolda, så tror jeg det hadde holdt 1 gang i uken.
Jobben måtte uansett hatt en modifikasjon av et slag som gjorde at den tok seg en ekstra pause mellom hver SNMP-forespørsel. Det er vel aldri gøy at ruter-CPUen går i taket, selv om det skjer bare én gang i uka.
Da har vi fått diskutert litt og avstemningen er i gang. Listen over saker er tilgjengelig på https://nav.uninett.no/wiki/nav-ref:navref_121115_avstemning , og vi ber om at dere selv rangerer og legger inn poengene på oppgavene - før neste fredag.
Takk.
On 12. jan. 2016 08:43, John Magne Bredal wrote:
Hei!
Vi har nå utarbeidet en liste over saker basert på sist nav-ref møte og den eksisterende listen. Vi vil gjerne at dere ser over den og kommenterer dersom det er mangler eller andre problemer med listen før førstkommende fredag.
Når det er gjort tar vi en avstemning på sakene i listen.
NB: Ingen avgir stemmer nå.
Listen med saker finnes på https://nav.uninett.no/wiki/nav-ref:navref_121115_avstemning
Stjernene er et estimat på både tid og kompleksitet for oppgaven, der en stjerne er minst og tre stjerner er mest kompleks. Spørsmålstegn angir stor usikkerhet i estimatet.
mvh.
On Fri, 22 Jan 2016 13:33:30 +0100 John Magne Bredal john.m.bredal@uninett.no wrote:
Da har vi fått diskutert litt og avstemningen er i gang. Listen over saker er tilgjengelig på https://nav.uninett.no/wiki/nav-ref:navref_121115_avstemning , og vi ber om at dere selv rangerer og legger inn poengene på oppgavene - før neste fredag.
Vil bare minne alle sammen på at fredag nærmer seg med stormskritt, og bare UiT har lagt inn stemmer foreløpig.
-- mvh Morten Brekkevold UNINETT
Ny prioriteringsliste er nå klar!
Takk til alle for utfylling og meninger om sakene.
https://nav.uninett.no/wiki/nav-ref:navref_121115_avstemning
On 22. jan. 2016 13:33, John Magne Bredal wrote:
Da har vi fått diskutert litt og avstemningen er i gang. Listen over saker er tilgjengelig på https://nav.uninett.no/wiki/nav-ref:navref_121115_avstemning , og vi ber om at dere selv rangerer og legger inn poengene på oppgavene - før neste fredag.
mvh.
-
Gro-Anita Hillestad Vindheim -
Jan Sigurd Refvik -
John Magne Bredal -
Morten Brekkevold -
Peder Magne Sefland