Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
@jonass
Behovet av API-nycklar Jag har lite svårt att förstå syftet med varför API-nyckeln ska behövas. Min magkänsla är snarare att detta är någon slags säkerhetsteater. Dessa är de potentiella syften jag kan utläsa:
1. Möjlighet att ur ett driftsäkerhetsmässigt sätt begränsa trafiken mot användare Om vi inte kan kräva en registrering med identifiering före uthämtning av API-nyckel så finns inte heller en realistisk teknisk möjlighet att med hjälp av API-nyckeln effektivt strypa påverkan på driftsäkerheten. Med min erfarenhet av bl.a. DDOS-attacker på några av sveriges största nyhetssajter så kan jag säga att det bästa sättet är utan tvivel att samarbeta med stora DDOS-skydd eller helt enkelt göra tjänsten så snabb och uppskalad att driften ändå inte blir problemet man behöver lösa med API-nyckeln.
Exempelvis med den föreslagna lösningen så ska nycklar inte krävas för tillgång. Då kan man tänka sig att en försvarsmekanism är att när man utsätts för problematisk trafik tillfälligt blockera all trafik som inte har API-nyckel och bara servera till de med API-nycklar. Problemet är att en attackerare kan göra så att det ser ut komma från nästan vilket IP-nummer som helst och dessutom slumpa vilket IP-nummer som används för varje förfrågan. För varje förfrågan så kan även en attackerare generera upp en ny slumpad nyckel eftersom nyckelrymden är stor.
I övrigt anser jag att rate-limiting i kombination med en uppskalad tjänst är hygiennivån för ett öppet konsumerat API precis som @salgo60 föreslår.
2. Möjlighet att debitera för högre servicenivå I din lösning har du angett alla parametrar som en användare behöver för att med relativt hög grad kunna tillförlitligt gissa sig till en användares API-nyckel(hashas url till användarkonto), det räcker med att jag skapar ett eget konto med en API-nyckel och testa mig fram till vilket krypto som används eftersom jag har all kunskap som behövs eller kan tillämpa statistiska metoder för att gissa salt med mera motmetoder.
En alternativ lösning (eftersom centraliserad öppen-data-api-nyckel är en bra idé om API-nyckel krävs för tillgång) skulle kunna vara genererade 2stycken uuid (client_id och client_token) som är helt slumpade men lagrad på ditt community-konto. Isåfall måste en lista med priviligerade tjänster och deras token etableras som får verifiera client_id och client_token mot en api-nyckels-verifierande tjänst etableras som övriga myndigheter(de priviligerade tjänsterna) kan använda.
En vidareutveckling på en sådan lösning skulle kunna vara att den centrala tjänsten tillhandahåller samtliga API-nycklar som en data-källa och en webhook-baserad lösning(förmodligen med en AMQP eller liknande lösning i botten som data-garant) för att kontinuerligt informera de priviligerade tjänsterna om nya och borttagna API-nycklar. Detta skulle lösa ett problem med driftsäkerheten för att vi inte har en single point of failure(SPOF) i API-nyckel-verifierings-tjänsten utan varje myndighet kan ha sin egen instans av den gemensamt ägda öppen-källkods-tjänsten.
Om vi inte skulle se denna API-nyckelslösning som en autentiseringslösning öppnas nämligen en potentiell attackyta där en elak 3:e part kan överanvända api-användarens nyckel vilket beroende på debiteringsmodell kostar den godartade användaren pengar utan att så menades.
3. Möjlighet att för registrerade betalande kunder hålla en separat instans Detta är en solid anledning att använda någon form av teknisk autentisering eller identifiering. Så att inte en attackerande part påverkar de betalande 3:e parternas prestanda likt det klassiska noisy-neighbour-problemet som är vanligt inom moln-infrastruktur.
Angående val av headers
FROM-headern Jag tycker detta verkar vara ett missbruk av en existerande header. Att använda en header på ett sätt som det inte är avsett är generellt inte att rekommendera. Om ni väljer att skapa upp e-post-adresser som client-id så kan det vara en god idé. T.ex: <user-uuid>@api-users.dataportal.se. Jag skulle rekommendera att använda from-fältet i kombination med Authorizationfältet som kan innehålla en token, exempelvis en JWT-token om ni vill på något vis scope:a token till vissa öppna API:er då ni kan skicka med scopes i JWT-tokenen och dela den nyckeln till den kryptokrafiska hashen av JWTn's innehåll med priviligerade tjänster.
FROM
<user-uuid>@api-users.dataportal.se
Det står utryckligen i MDN:
You shouldn't use the From header for access control or authentication.
I HTTP-standarden är det ganska tydligt att det borde vara en e-post-adress.
The "From" header field contains an Internet email address for a human user who controls the requesting user agent. The address ought to be machine-usable, as defined by "mailbox" in Section 3.4 of [RFC5322].
@eric vart rapporterar jag brister? Har ni publicerat källan till specen på github eller gitlab eller så där vi kan anmäla issues, för diskussion eller komma med förbättringsförslag?
@jonor sa i Hjälp folk att bada i sommar med Öppna Data! (Tips och hjälp behövs):
@stefan-wallin [...] Jag förstår att Riksantikvarieämbetet håller reda på sina egna id-nummer, som refereras från Wikidata-objektet i ditt exempel, men jag förstår inte betydelsen av "lokala" i sammanhanget, innebär det att de inte är publicerade som URI:er, men kopplas till ett Q-nummer på Wikidata?
Med lokala så syftar jag helt enkelt på system-lokala unika persistenta identifierare. I kontrast till en global unik persistent identifierare. Med lokaliteten så syftar jag till att många olika organisationer kan ha sina egna identifierare utan att börja med någon slags sammanslagningar eller liknande då vi riskerar duplikat när andra organisationer identifierar samma objekt.
En global identifierare är en identifierare som många aktörer knyter sig till och riskerar skapa dubletter av i ett på något sätt publikt redigerbart system (inte nödvändigtvis wiki, kanske git-repo med PR eller annat system för kors-organisations-förändring). För att en global identifierare ska blir relevant krävs det att datan där håller hög kvalitet och accepteras av många organisationer inom samma bransch för kunna skaffa sig en sådan status.
Exempel på system som håller sådana globala identifierare skulle kunna vara OSM eller Wikidata.
Vi skulle även kunna resonera som så att vi i sverige vill ha ägande över en nationell persistent identifierare. En sådan skulle vi kunna kalla en regional eller nationell persistent identifierare. Där skulle t.ex. DIGG eller RAÄ sätta upp en egen wikibase-instans dit alla kommunala och regionala system knyter sina persistenta identifierare till. Denna wikibase-instans skulle sedan kunna vara en instans dit externa system som OSM eller wikidata knyter an till. Detta skulle också kunna möjliggöra korskoppling av datapunkter mellan olika myndigheter. T.ex. kanske lantmäteriet, en kommun och havochvatten vara intresserade av samma badplats. Då skulle kunna vara intressant att knyta ihop dessa system utifrån den nationella persistenta identifieraren.
Jag skulle vilja få tillgång inte bara till öppna data, utan också skyddad data men som handlar om mig själv, så jag kan bygga tjänster där medborgarna kan utgå från sin egen data.
Exempelvis skulle jag vilja:
Ett förslag till hur detta skulle kunna fungera är att DIGG hjälper till att samordna ett sätt att där jag som medborgare med hjälp av e-legitimation kan genomgå en oauth-liknande flöde och ge en tjänsteanvändare möjlighet att ge en tjänst tillgång till min och de entiteter jag är ombud för's persondata eller organisationsdata inom det offentliga. Det bör kunna finnas ett enhetligt sätt att göra detta snarare än att varje myndighet ska ta fram detta själva.
Det finns flera sorters data i öppna APIer men varje API tenderar att hålla sig inom samma sort. Exempel på datasorter:
Det finns säkert någon slags datasort jag missat, men jag är ofta helt ointresserad av statistik som jag uppfattar upptar majoriteten av dataseten. Jag skulle önska en möjlighet att filtrera ut vissa av dessa kategorier när jag bläddrar igenom den oöverskådliga mängden av 7000+ API:er. Jag har exempelvis varit deltagare och organisatör på flertalet hackathons och problemet är att det är ofta helt oöverstigligt att sortera igenom denna enorma mängd av API:er för att hitta något intressant att basera en affärsidé eller verktygsidé på.
Är det någon som känner till en specifik standard för hur man kan uttrycka sina API-specar i ett maskinkonsumerbart format där fälten är entiteter à la länkade data men ändå har ett litet fotavtryck på överföringsmängden.
Säg t.ex att jag vill lägga upp ett API för att publicera nyhetsbilder(obs: inget som finns på någon roadmap hos oss!). Då skulle bilden kunna föreställa olika objekt typ personer och platser
Exempelvis skulle en bild av Ardalan Shekarabi kunna representeras såhär:
{ image: url, caption: { sv: “” }, description: { sv: “” }, people: [ { name: “Ardalan Shekarabi”, sameAs: “Q4787806”, } ] }
Men hur gör man ett API som en länkaddata-aggregator kan förstå instinktivt snarare än ytterligare ett sätt att speca ett API?
@josefinlassi lite synd att ni känner att ni måste jobba vidare med en exclude-funktionalitet. I en korrekt vald arkitektur så skulle, som @salgo60 redan påtalat, det redan fungera.
T.ex. om ni skulle ha en wikibase-installation som bas så är det bara ytterligare ett attribut som ni kan lägga på och det måste inte finnas på alla API:er. Då skulle vi kunna låta våra pengar gå till exempelvis att bygga wikigames som hjälper administratörer och frivilliga att fylla i uppgifterna i schyssta gui och låta API-nyttjare filtrera med sparql-frågor, eller till och med bygga schysta sparql-filtrerings-gui:n
"antal datapunkter" är på sätt och vis ett konstigt attribut eftersom det oftast ändrar sig över tid. Även antalet kommuner har ju ändrats över tid (1952 var det över 2000 kommuner i Sverige). Det är ju även så att inte bara storleken utan även hastigheten är intressant för att uppfatta eventuella skalningsproblem eller om datan är omfattande nog.
För "dessa datamängder bygger på samma specifikation" så är du ju inne på det som @salgo60 pratar om när det gäller persistenta identifierare av specifikationen och en referens till den identifieraren bör finnas med i filtreringsurvalet och data-mängden.
@salgo60 Känns som att du bör skicka in ett mail som hamnar hos registratorn och ber de lämna ut persistenta identifierare eller kontaktuppgifter till den tekniska förvaltaren hos havochvatten snarare än att fastna i PR-maskineriet som är svenska myndigheters sociala-medie-konton.
@stefan-wallin Är man lite extra gnetig kan man nog slänga in alla bad som både OSM och havochvatten har plus de som VGR har i en postgis eller liknande och hitta vilka som skapar geo-konflikter och därmed hitta överlapp. Tyvärr har jag inte riktigt tid över i livet att göra det själv, men kan gärna rådge om någon skulle vara intresserad av det.
@tomasmonsen angående CSV vs. JSON så håller jag med om att JSON vore att föredra.
Jag förstår ditt verksamhetsproblem med vart datan kommer ifrån. Om man bara vill komma igång så gör du ett JSON-Schema, klistrar in på https://www.jeremydorn.com/json-editor i "Schema"-rutan och då får du GUI högst upp.
Högst upp till höger har du en direkt-länk-skapande länk, när du matat in ditt JSON-schema så kan du länka in ditt JSON-schema i editorn och dela den länken med personalen som ska fylla i.
Process:
@salgo60 sa i Hjälp folk att bada i sommar med Öppna Data! (Tips och hjälp behövs):
@istyf du har en bra identitet i NUTS - Nomenklaturen för statistiska territoriella enheter (Wikidata property:P605) och det finns bra data hos Havs- och vattenmyndighetens i Sverige med API. Jag lägger nu upp dom badplatser dom definierat i Wikidata se github.com/salgo60/Svenskabadplatser Fundering skapar vi med Öppen Data massa data SILOS ser massa dataset om badplatser som laddas upp utan att referera NUTS --> blir massa DataSILOS känns feltänkt att dubblera det jobb som en myndighet med tydligt ansvar gör som en del av sitta uppdrag deras API har kopplingar till vattenprover etc. länk API detail request jag kopplar badplatserna till Open Street Map och även sociala medier, sjö ett bad finns vid, vilken landform den finns på oftast ö, om badet finns i ett Naturreservat.... Jag hade i veckan kontakt med Havs- och vattenmyndighetens i Sverige och citat 1: Ja det är unika persistenta ID som vi har, med reservation för att vi har flyttat enstaka bad från en kommun till en annan, då får badplatsen också ett nytt ID eftersom kommunens id-nr är del av ID:t. Samt om en kommun av någon anledning markerar ett bad som inaktivt och sedan registrerar ett nytt med samma namn och koordinater så kommer det ”nya” att ha ett nytt id. BORDE inte inträffa, men kan ju hända…
@istyf du har en bra identitet i NUTS - Nomenklaturen för statistiska territoriella enheter (Wikidata property:P605) och det finns bra data hos Havs- och vattenmyndighetens i Sverige med API. Jag lägger nu upp dom badplatser dom definierat i Wikidata se github.com/salgo60/Svenskabadplatser
Jag hade i veckan kontakt med Havs- och vattenmyndighetens i Sverige och citat
1: Ja det är unika persistenta ID som vi har, med reservation för att vi har flyttat enstaka bad från en kommun till en annan, då får badplatsen också ett nytt ID eftersom kommunens id-nr är del av ID:t. Samt om en kommun av någon anledning markerar ett bad som inaktivt och sedan registrerar ett nytt med samma namn och koordinater så kommer det ”nya” att ha ett nytt id. BORDE inte inträffa, men kan ju hända…
Är inte nyckeln i detta problem att det finns badplatser som inte havochvatten har prickat ut och hur en större mängd distribuerade organisationer som sedan skapar nya sådana identifierare utan att skapa id-krockar?
@jonor den där introduktionen pratar ju om RDF som är 4e nivån i 5-star data. Länkad data är när vi kopplar ihop dem.
På wikidata har du till exempel det jag kallar "lokala identifierare" om vi tittar på https://www.wikidata.org/wiki/Q10717929 längst ned där du har RAÄ-nummer t.ex.
Läs gärna mer på 5stardata.info och ställ fler frågor om det är oklart.
Jag svarar här också, svarade först på twitter: https://twitter.com/Stefan_Wallin/status/1387785992996859908
Är man gnetig så kan man nog mappa upp baden som @havochvatten (verkar inte finnas här på dataplattformen) använder i sin tjänst badplatsen.
En xml-fil med alla bad som havochvatten har koll på: https://badplatsen.havochvatten.se/badplatsen/api/feature/
Där ser baden ut såhär:
<wfs:member> <hav-miljoovervakning:badplatsen gml:id="badplatsen.fid-58b61a0b_1791e1e86d2_2165"> <hav-miljoovervakning:NUTSKOD>SE0441273000000001</hav-miljoovervakning:NUTSKOD> <hav-miljoovervakning:NAMN>Vesljungasjön</hav-miljoovervakning:NAMN> <hav-miljoovervakning:KMN_NAMN>Osby</hav-miljoovervakning:KMN_NAMN> <hav-miljoovervakning:PRTPG_GEOPOSITION> <gml:Point srsDimension="2" srsName="http://www.opengis.net/gml/srs/epsg.xml#4326"> <gml:pos>13.7674095026078 56.4212500165633</gml:pos> </gml:Point> </hav-miljoovervakning:PRTPG_GEOPOSITION> </hav-miljoovervakning:badplatsen> </wfs:member>
Den stora frågan är ju om man ska använda gml:id eller NUTSKOD som persistent identifierare. Om någon av dem nu går att lita på
gml:id
NUTSKOD
NUTSKOD verkar ju i alla fall användas i deras kart-tjänst badplatsen, https://badplatsen.havochvatten.se/badplatsen/karta/#/bath/SE0441273000004182, så vi kan ju hoppas att det är en semi-persistent identifierare. Sen saknas ju många bad, men det är säkert en bra början.
@istyf sa i Hjälp folk att bada i sommar med Öppna Data! (Tips och hjälp behövs):
En metod för namngivningen kan till exempel vara någon form av namespace som se.toreboda.anlaggningar.badstrand.217
Vad syftar toreboda på, en kommun? Vad händer om kommunen slås ihop med grannkommunen, ska identifieraren ändras då? Isåfall är den inte persistent imho. Vad händer om anläggningen slutar vara kommununderhållen och istället överlåts i privat ägo, vad händer med källsystemet som håller referensen då? Är den fortfarande persistent?
Enklast är nog att försöka ha en gemensam referensdatabas över persistenta identifierare, t.ex. Wikidata
Sen kan man ha lokala persistenta identifierare också, men då behöver de kopplas ihop.
