Forum Mjukvara Programmering och digitalt skapande Tråd Inlägg

förslag på programflöde, auth mot server. Sen POST...

1
Skriv svar
Permalänk
Medlem
●

förslag på programflöde, auth mot server. Sen POST...

Jag har blivit ålagd och spara data (var 10:e minut ny post) på en server som kräver authentication - och jag är totalt novis på detta. Har fått information om url och sen ett TOKEN (lång nyckel) samt hur headern ska se ut för att ex.vis rapportera nytt data (.m.h.a POST).
Jag har ett API att tillgå med GET, PUT, POST, DELETE.
Jag lyckades skicka en GET och då fick jag id och ett annat token som svar. Jag anar att det är en nyckel som ska anv. i kommande kommunikation?
Det sades att access tiden är 180 dagar för nyckeln (vilken nyckel?). Får begära en ny sen m.h.a "huvudnyckeln" vad nu det är.

Det jag undrar över är flödet för att skicka data från morgon till em varje minut till denna server.
Eftersom jag jobbar i labview för tillfället så har jag block att jobba med; OpenHandle. CloseHandle. GET. POST....etc...samt Add Header, Remove Header, Get Header etc....

  1. Begära nyckel med GET? Spara den i 179 dagar? (Redan gjort)

  2. OpenHandle (skapar ett ID som används genom hela kedjan...)

  3. Skicka ny data med POST och med TOKEN (vilket?) i headern. (Har exempel på hur headern ska se ut)

  4. Repetera steg 3 (om reject från server, försök igen om 10 min typ)

  5. Slut för dagen? Stäng förbindelsen med CloseHandle

Är detta rätt väg? Är nyckeln jag fick med GET en nyckel som är framtagen m.h.a nåt cert som finns på min dator?

Tacksam för hjälp

Redigera
Citera flera Citera
Permalänk
Medlem ★
●

Har du ingen kravställare eller annan utvecklare att fråga om dessa antaganden? Är sällan bra att koda saker på antaganden, för det du antar är inte säkert den som vill ha produkten antar.

Då man pratar om token så är det ofta JWT bearer tokens som används vid apier och skickas med som en authentication header i anropet till servern. Är det den du får via GET så kan du anropa och cacha det som du gör i 180 dagar från att du fick den. Sen ska den med i alla POST anrop till servern.

Detta skulle du kunna skapas upp som något automatiskt schemalagt webjob.

Vilket språk kodar du i?

Redigera
Citera flera Citera
Permalänk
Medlem
●

Normalt så när det är så "lång" lease så har jag koden inskriven som en Docker secret då jag kör alla mina BE i docker containers
då behöver jag bara logga in i podden och uppdatera den när det behövs och jag lägger en påminnelse i min telefon 3veckor innan så jag har det i rätt "sprint"

jag gör alla mina tester med PostMan manuellt först så jag vet att kommunikationen funkar innan jag kopplar på datorn.
därför har jag redan "nyckelen"

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av zaibuf:

Har du ingen kravställare eller annan utvecklare att fråga om dessa antaganden? Är sällan bra att koda saker på antaganden, för det du antar är inte säkert den som vill ha produkten antar.

Då man pratar om token så är det ofta JWT bearer tokens som används vid apier och skickas med som en authentication header i anropet till servern. Är det den du får via GET så kan du anropa och cacha det som du gör i 180 dagar från att du fick den. Sen ska den med i alla POST anrop till servern.

Detta skulle du kunna skapas upp som något automatiskt schemalagt webjob.

Vilket språk kodar du i?

Gå till inlägget

Jag kodar i Labview. "Eftersom jag jobbar i labview för tillfället så har jag block att jobba med; OpenHandle. CloseHandle. GET. POST....etc...samt Add Header, Remove Header, Get Header etc....". (Sen har jag ytterligare block som hanterar Security, exvis SetAPIKey vilken har parametrarna access id och secret id.)

Jag tänker mig att just identifieringen och nyckelutbytet etc. sker enligt en standardiserad mall. Det är precis som du säger, att vi använder JWT bearer (denna ska användas i headern vet jag). När väl det är gjort så har jag enbart POST att använda mig av. Men det är standardförfarandet INNAN jag använder POST jag är osäker på. Kommandot GET jag skickade och fick tillbaka en nyckel, är det en nyckel som är framtagen m.h.a ett certifikat jag redan har? (Kom ihåg att jag är novis på detta). Ska den nyckeln användas i headern framgent i x antal dagar tills jag måste förnya den?

Redigera
Citera flera Citera
Permalänk
Medlem ★
●
Skrivet av Sweedland:

Jag tänker mig att just identifieringen och nyckelutbytet etc. sker enligt en standardiserad mall. Det är precis som du säger, att vi använder JWT bearer (denna ska användas i headern vet jag). När väl det är gjort så har jag enbart POST att använda mig av. Men det är standardförfarandet INNAN jag använder POST jag är osäker på.

Gå till inlägget

Det låter som att den standardiserade mallen är OAUTH2, standardiserad i IETF RFC 6749 och därefter utbyggd och förändrad. Resten av det här inlägget bygger på det antagandet.

I så fall behöver du veta vilken "grant type" som ska användas, ifall du vill kunna följa standarden (och för all del ifall du vill att någon ska kunna hjälpa dig med detaljerna).

Har du inte fått dokumentation i form av curl-anrop eller liknande?

Om du har lyckats få ut ett access token är det bara att köra på med POST-anropen.

Du har eventuellt också haft möjlighet att få ut ett refresh token. Ett sådant token kan användas för att i ett enda anrop skaffa ett nytt access token med ytterligare 180 dagars giltighet. Om du i stället gör om ursprungsanropet för att skaffa ett access token så kommer vissa implementationer att returnera samma access token igen, vilket gör att giltighetstiden inte ökar.

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av KAD:

Det låter som att den standardiserade mallen är OAUTH2, standardiserad i IETF RFC 6749 och därefter utbyggd och förändrad. Resten av det här inlägget bygger på det antagandet.

I så fall behöver du veta vilken "grant type" som ska användas, ifall du vill kunna följa standarden (och för all del ifall du vill att någon ska kunna hjälpa dig med detaljerna).

Har du inte fått dokumentation i form av curl-anrop eller liknande?

Om du har lyckats få ut ett access token är det bara att köra på med POST-anropen.

Du har eventuellt också haft möjlighet att få ut ett refresh token. Ett sådant token kan användas för att i ett enda anrop skaffa ett nytt access token med ytterligare 180 dagars giltighet. Om du i stället gör om ursprungsanropet för att skaffa ett access token så kommer vissa implementationer att returnera samma access token igen, vilket gör att giltighetstiden inte ökar.

Gå till inlägget

Jo. Jag har bash filer med curl-anrop och tillhörande headers. Jag ska läsa länken!

Hur inkluderar man bilder i denna text? Skulle vara intressant om man fick en feedback på LV:s hantering.

Redigera
Citera flera Citera
Permalänk
Medlem
●
Skrivet av KAD:

Det låter som att den standardiserade mallen är OAUTH2, standardiserad i IETF RFC 6749 och därefter utbyggd och förändrad. Resten av det här inlägget bygger på det antagandet.

I så fall behöver du veta vilken "grant type" som ska användas, ifall du vill kunna följa standarden (och för all del ifall du vill att någon ska kunna hjälpa dig med detaljerna).
....

Gå till inlägget

Har insett en sak. Är en authorization server med i bilden? Är den i samma "dator" som man tror man kommunicerar med?

https://docs.authlib.org/en/latest/oauth/2/intro.html

edit:
Jag fick mer info nu. Autentiseringen följer inte standard. Sååå....jag skulle få en manual.
End of thread.

Senast redigerat
Redigera
Citera flera Citera
1
Skriv svar