Fórum Root.cz
Hlavní témata => Sítě => Téma založeno: neregistrovany 11. 04. 2024, 09:55:57
-
Máme na vnitřní síti systém, který si občas tahá data z API služby Fakturoid. Deset let to chodilo přes API token, ale teď přecházejí na OAuth se kterým jsem ještě nepřišel do styku. Co jsem si o tom zatím četl, vypadá to na nutnost mít web server na veřejné adrese (což nemáme a byla by to do určité míry komplikace).
Je to skutečně principiální nutnost, nebo to lze nějak provozovat i bez toho?
-
Předpokládám, že se vaše aplikace autentizuje vůči Fakturoidu. Pak to obecně není potřeba, protože chodí požadavky z prohlížeče na váš systém, z prohlížeče na Fakturoid a z vašeho systému na Fakturoid. Leda že by tam měli nějaké rozšíření, že by se i Fakturoid chtěl dotazovat vašeho systému – ale obecně pro OAuth tento směr komunikace není potřeba.
-
Předpokládám, že se vaše aplikace autentizuje vůči Fakturoidu.
ano
Pak to obecně není potřeba, protože chodí požadavky z prohlížeče na váš systém, z prohlížeče na Fakturoid a z vašeho systému na Fakturoid.
Úplně nevím jakou roli v tom hraje prohlížeč. Data z fakturoidu teď taháme curl scriptem. Script zná API token, a jediným HTTP požadavkem je stahne do našeho systému. Toto bychom (pokud to bud emožné) rádi zachovali i s OAuth.
Leda že by tam měli nějaké rozšíření, že by se i Fakturoid chtěl dotazovat vašeho systému – ale obecně pro OAuth tento směr komunikace není potřeba.
Ve formuláři kterým se na stránkách DFakturoidu vytváří "Nová OAuth integrace" je políčko "URL pro přesměrování" ke kterému mi support napsal:
"Link pro přesměrování je URL, které bude volané Fakturoidem během autorizace, je to nedílná součást protokolu OAuth 2.0"
tak právě nevím...
-
tak si ten protokol pročti.
Jedná se o adresu, kam tě má fakturoid přesměrovat poté, co dokončí svoji práci, jedná se o web, která stačí, když máš dostupný od sebe a nikoliv z fakturoidu, často to může být klidně localhost (ikdyž to logicky spousta poskytovatelů nepodporuje).
-
Redirect potrebujete hlavne pro authorization code flow, ale koukam letmo na dokumentaci k fakturoidu a podporuje i client credetials codeflow, kde dostanete rovnou access a refresh token na zaklade jmena, hesla, client_id a asi i client_secretu. Pro Vas curl bych zvolil tuto moznost. V podstate se jedna o post na https:<url>/oauth/token. Curl bude vypada pak nejak takhle:
curl -X POST "$URL"
-H "Content-Type: application/x-www-form-urlencoded" \
-d "username=$USERNAME" \
-d "password=$PASSWORD" \
-d 'grant_type=password' \
-d "client_id=$CLIENT_ID" \
-d "client_secret=$CLIENT_SECRET" \
-d "scope=openid"
Pri requestu na api pak access token nacpete do hlavicky "Authorization: Bearer <ACCESS_TOKEN>". Refresh token si muzete (ale nemusite) ulozit, takze priste si token vyzvednete pres nej a ne pres username/password :)
https://www.fakturoid.cz/api/v3/authorization#client-credentials-flow
-
Jinak authorization code flow (kdy potrebujete ten redirect) se pouziva hlavne ve chvili, kdy chcete aby Vas backend dostal primo access token a token nesel na frontend. Pak Vam IdP vyda pouze kod a redirect na Vasi cast backendu, ktera s timto auth codem provola znovu idp a dostane access a refresh token. Na zaklade nich Vas backend jedna jedna autentizuje (jste prihlasen) a na zaklade claimu a pozadovaneho scopu muze i authorizovat, tzn svazat Vassi session s konkretnimi pravy na danych endpointech. Vyhoda je i podpora ruznych public idp jako facebook, google apod, kdy na zaklade uctu na techto platformach ziskate opravneni do nejake 3rd (klidne Vasi aplikace). Pokud touzite si rozchodit vlastni idp pak doporucuji treba keycloak, pripadne na stejnych principech stoji tusim i azure ad. OIDC vladne svetu :)
-
V OAuth vystupují 4 subjekty:
- Autentizační server (k tomu se uživatel přihlašuje, třeba tam zadá jméno a heslo) – ve vašem případě Fakturoid
- Resource server, poskytovatel dat – server, který má data, ke kterým chcete získat přístup. Ve vašem případě také Fakturoid.
- Služba, která chce získat přístup – to je váš backend.
- Uživatel a typicky jeho prohlížeč – ten, kdo uděluje přístup službě ke zdrojům, váš uživatel.
Celé to pak vypadá tak, že uživatel chce vaší službě předat nějaké údaje. Takže navštíví vaši službu, ta ho přesměruje na autentizační server. Tam se přihlásí svými údaji a je přesměrován zpět na vaši službu, ale v rámci přesměrování získá i přístupový token. A tento token už může vaše služba využít pro přístup ke požadovanému zdroji.
Vtip je v tom, že uživatel nepředá své přihlašovací údaje k Fakturoidu vám, ale použije je přímo na Fakturoidu, kde třeba ještě může říct, k čemu můžete mít přístup. Třeba že můžete jen vytvořit novou fakturu, ale ne získat informace o ostatních fakturách (teoreticky, nevím, zda to tak zrovna Fakturoid má). Vy pak máte token (obvykle s omezenou časovou platností), který vás opravňuje v omezeném rozsahu volat služby Fakturoidu jménem uživatele.
Zároveň uživatel nemusí někde generovat nějaké tokeny a vkládat je do vaší aplikace, ale normálně se přihlásí na stránce Fakturoidu tak, jak je zvyklý.
Ta URL pro přesměrování právě svědčí o tom, že se používá přihlašování přes prohlížeč (pravděpodobně code flow). A je to URL, kam bude uživatel přesměrován po té, co se na Fakturoidu přihlásí. Tedy to musí být adresa, která je dostupná z uživatelova prohlížeče. Nemusí to být veřejná adresa, Fakturoid se k ní nebude připojovat, je jen pro toho uživatele (resp. jeho prohlížeč).
-
tak si ten protokol pročti.
Jedná se o adresu, kam tě má fakturoid přesměrovat poté, co dokončí svoji práci, jedná se o web, která stačí, když máš dostupný od sebe a nikoliv z fakturoidu, často to může být klidně localhost (ikdyž to logicky spousta poskytovatelů nepodporuje).
Já si o něm četl, ale úplně jsem to zatím nepobral.
Píšou tam "url bude volané fakturoidem" (což chápu jako "ze severu fakturoidu"), jak se dostane fakturoid na muj localhost (za firewallem) netusim.
-
pouzijte client credentials a neresite zadnej redirect :). Je to jen jeden curl navic a parsovani tokenu pres jq.
-
Tedy to musí být adresa, která je dostupná z uživatelova prohlížeče. Nemusí to být veřejná adresa, Fakturoid se k ní nebude připojovat, je jen pro toho uživatele (resp. jeho prohlížeč).
Proč tedy ze supportu píšou "link pro přesměrování bude VOLÁN FAKTUROIDEM během autorizace". Nebo tím myslí "javascriptem fakturoidu běžícím v browseru"?
Navíc jsem už psal že u mě teď žádný browser nehraje roli, vše se děje pomocí scriptů. Třeba výpisy se tahají schedulovaně na pozadí... "user" (token) je stále stejný (dokud exepiruje). Prostě necháput tu roli browseru v tom procesu, přece se to musí dát udělat nějak "neiteraktivně".
-
pouzijte client credentials a neresite zadnej redirect :). Je to jen jeden curl navic a parsovani tokenu pres jq.
To bych právě moc rád, ale při registraci OAuth tam Fakturoid vyžaduje to redirektovací URL, bez toho nejde se k jejich OAuth nejde registrovat.
-
ne nevyzaduje, kdyz si tu dokumentaci prectete poradne, tedy dojedete az nakonec tak credentials flow se nijak nenastavuji pouze ziskate sve client_id a client_secret (pak je tam odkaz na rfc). A s temito informacemi pak zavolate ten curl co jsem Vam poslal vyse a mel byste dostat token s response code 200. Zadnej redirect.
Before you start go to your Fakturoid account and download your Client ID and Client Secret from your user screen Settings → User account.
https://www.fakturoid.cz/api/v3/authorization#client-credentials-flow
-
Pokud je nelogicky vyžadují ve formuláři, tak tam nějakou url zadej, zkus třeba ten localhost, to se pak dobře ladí, pokud jí nepoužiješ a fakturoid umožňuje volat oauth/token, je jedno co tam je.
Podpora asi píše o prohlížeči a volání url, protože použití v prohlížeči je pro ně nejčastější, nerozumí přesně tomu jak to funguje (stejně jako ty). Prohlížeč si nahraď za curl, ten protokol je poměrně jasně popsaný.
-
ne nevyzaduje, kdyz si tu dokumentaci prectete poradne, tedy dojedete az nakonec tak credentials flow se nijak nenastavuji pouze ziskate sve client_id a client_secret (pak je tam odkaz na rfc). A s temito informacemi pak zavolate ten curl co jsem Vam poslal vyse a mel byste dostat token s response code 200. Zadnej redirect.
Before you start go to your Fakturoid account and download your Client ID and Client Secret from your user screen Settings → User account.
https://www.fakturoid.cz/api/v3/authorization#client-credentials-flow
Tak jsme to zkusil, snad to mam dobre
curl -X POST "https://app.fakturoid.cz/api/v3/oauth/token" -H "Content-Type: application/x-www-form-urlencoded" -d "username=muj_login_do_fakturoidu" -d "password=moje_heslo_do_fakturoidu" -d "grant_type=password" -d "client_id=moje_id" -d "client_secret=muj_secret" -d "scope=openid"
ale vyhodilo to error
{"error":"invalid_request","error_description":"Only JSON requests are allowed."}
-
aaa jasny, nevsim sem si ze ten odkaz na ten POST v fakturuid dokumentaci pro cloent credentials je klikaci a je tam priklad kde maj bejt jaky hodnoty. Bohuzel ted nejsem u pocitace, zkuste to sam a kdyby to neslo pastnu to vecer
-
pouzijte client credentials a neresite zadnej redirect :). Je to jen jeden curl navic a parsovani tokenu pres jq.
To těžko. Za prvé by to musel podporovat Fakturoid, za druhé tenhle typ autentizace asi těžko bude chtít Fakturoid podporovat pro aplikace třetích stran, protože by to znamenalo, že uživatel musí vaší aplikaci předat autentizační údaje od Fakturoidu. Což je přesně to, čemu se celý OAuth snaží vyhnout – proto vznikl.
-
Proč tedy ze supportu píšou "link pro přesměrování bude VOLÁN FAKTUROIDEM během autorizace". Nebo tím myslí "javascriptem fakturoidu běžícím v browseru"?
Na ten link bude Fakturoidem přesměrován prohlížeč uživatele.
Navíc jsem už psal že u mě teď žádný browser nehraje roli, vše se děje pomocí scriptů. Třeba výpisy se tahají schedulovaně na pozadí... "user" (token) je stále stejný (dokud exepiruje). Prostě necháput tu roli browseru v tom procesu, přece se to musí dát udělat nějak "neiteraktivně".
Role prohlížeče je ta, že přes něj se přihlásí uživatel Fakturoidu a udělí vám přístup. Na základě toho vám Fakturoid (při tom přesměrování) předá token, který budete používat pro přístup jménem toho uživatele.
Pokud to má být dlouhodobý přístup, možná ty tokeny budou dva – refresh token, který bude mít dlouho platnost a uživatel ho může zneplatnit, a ten pak v okamžiku komunikace vyměníte za access token, který bude mít platnost jen pár minut nebo možná hodin, a ten použijete teprve při samotném volání API.
Nainteraktivně to nejde, Fakturoid vám přece nemůže dát přístup k datům všech uživatelů. Musí tam být interakce uživatele, který schválí, že vaše aplikace má mít přístup k jeho údajům.
-
https://www.fakturoid.cz/api/v3/authorization#client-credentials-flow
To je ale použitelné jedině v případě, kdy jeden uživatel používá svou aplikaci, které důvěřuje a které je ochoten dát své přístupové údaje k Fakturoidu. O tom, že by to byla takováto soukromá aplikace, nebyla nikde v dotazu řeč. Ale je pravda, že to dotaz ani nevylučuje.
Každopádně je potřeba si přečíst ty první tři odstavce dokumentace https://www.fakturoid.cz/api/v3/authorization a rozhodnout se, který typ aplikace máte. Pokud si vyberete „Client Credentials Flow“, tam se redirect URL nepoužívá. Tu položku mají chybně ve formuláři povinnou, tak tam vyplňte libovolné URL.
-
pouzijte client credentials a neresite zadnej redirect :). Je to jen jeden curl navic a parsovani tokenu pres jq.
To těžko. Za prvé by to musel podporovat Fakturoid, za druhé tenhle typ autentizace asi těžko bude chtít Fakturoid podporovat pro aplikace třetích stran, protože by to znamenalo, že uživatel musí vaší aplikaci předat autentizační údaje od Fakturoidu. Což je přesně to, čemu se celý OAuth snaží vyhnout – proto vznikl.
No ale on to ten fakturoid podporuje - je to te dokumentaci, ze :). Jen misto uzivatel/heslo tam mate pouze client_id a client_secret ktery je svazany s tim userem (nicmene v ramci oidc muzete chtit i jmeno a heslo. V kazdym slusnym idp tohle normalne nastavite.
-
Proč tedy ze supportu píšou "link pro přesměrování bude VOLÁN FAKTUROIDEM během autorizace". Nebo tím myslí "javascriptem fakturoidu běžícím v browseru"?
Na ten link bude Fakturoidem přesměrován prohlížeč uživatele.
Navíc jsem už psal že u mě teď žádný browser nehraje roli, vše se děje pomocí scriptů. Třeba výpisy se tahají schedulovaně na pozadí... "user" (token) je stále stejný (dokud exepiruje). Prostě necháput tu roli browseru v tom procesu, přece se to musí dát udělat nějak "neiteraktivně".
Role prohlížeče je ta, že přes něj se přihlásí uživatel Fakturoidu a udělí vám přístup. Na základě toho vám Fakturoid (při tom přesměrování) předá token, který budete používat pro přístup jménem toho uživatele.
Pokud to má být dlouhodobý přístup, možná ty tokeny budou dva – refresh token, který bude mít dlouho platnost a uživatel ho může zneplatnit, a ten pak v okamžiku komunikace vyměníte za access token, který bude mít platnost jen pár minut nebo možná hodin, a ten použijete teprve při samotném volání API.
Nainteraktivně to nejde, Fakturoid vám přece nemůže dát přístup k datům všech uživatelů. Musí tam být interakce uživatele, který schválí, že vaše aplikace má mít přístup k jeho údajům.
Neinteraktivne to pochopitelne v tomhle pripade take jde :). Jen misto jednoho curlu to budou dva. V jednom dostanete code a ten pak ten vymenite za access token. Na redirect se vyprdnete, resp. musite ho specifikovat kdyz zadate o code. Je to dano tim ze vsechny endpointy (jak pro code, tak i pro exchange code/tokeny jsou verejne dostupne). Ten redirect je pouze pro to, aby to moh delat backend. Coz ale v tomhle pripade neni ten scenar kterej tazatel chce.
-
No ale on to ten fakturoid podporuje - je to te dokumentaci, ze :). Jen misto uzivatel/heslo tam mate pouze client_id a client_secret ktery je svazany s tim userem (nicmene v ramci oidc muzete chtit i jmeno a heslo.
Pardon, já jsem to předtím napsal špatně. Při Client Credentials flow se standardně nepředává jméno a heslo, ale identifikace klienta – a klient je ta aplikace, ne uživatel. Takže se tam client_id a client_secret nepředává místo jména a hesla, ale proto, že se to obvykle při Client Credentials flow předávají právě tyhle údaje jako autentizace klienta (= aplikace).
Když se předává přímo jméno a heslo uživatele, je to Resource owner credentials flow.
-
Proč tedy ze supportu píšou "link pro přesměrování bude VOLÁN FAKTUROIDEM během autorizace". Nebo tím myslí "javascriptem fakturoidu běžícím v browseru"?
Na ten link bude Fakturoidem přesměrován prohlížeč uživatele.
Navíc jsem už psal že u mě teď žádný browser nehraje roli, vše se děje pomocí scriptů. Třeba výpisy se tahají schedulovaně na pozadí... "user" (token) je stále stejný (dokud exepiruje). Prostě necháput tu roli browseru v tom procesu, přece se to musí dát udělat nějak "neiteraktivně".
Role prohlížeče je ta, že přes něj se přihlásí uživatel Fakturoidu a udělí vám přístup. Na základě toho vám Fakturoid (při tom přesměrování) předá token, který budete používat pro přístup jménem toho uživatele.
Pokud to má být dlouhodobý přístup, možná ty tokeny budou dva – refresh token, který bude mít dlouho platnost a uživatel ho může zneplatnit, a ten pak v okamžiku komunikace vyměníte za access token, který bude mít platnost jen pár minut nebo možná hodin, a ten použijete teprve při samotném volání API.
Nainteraktivně to nejde, Fakturoid vám přece nemůže dát přístup k datům všech uživatelů. Musí tam být interakce uživatele, který schválí, že vaše aplikace má mít přístup k jeho údajům.
Neinteraktivne to pochopitelne v tomhle pripade take jde :). Jen misto jednoho curlu to budou dva. V jednom dostanete code a ten pak ten vymenite za access token. Na redirect se vyprdnete, resp. musite ho specifikovat kdyz zadate o code. Je to dano tim ze vsechny endpointy (jak pro code, tak i pro exchange code/tokeny jsou verejne dostupne). Ten redirect je pouze pro to, aby to moh delat backend. Coz ale v tomhle pripade neni ten scenar kterej tazatel chce.
Teď úplně nerozumím, o čem píšete. O kterém flow vlastně píšete. V případě Authorization Code Flow vám cUrl nepomůže, protože tam se musí uživatel v prohlížeči autentizovat a může to dělat třeba pomocí biometrie. Pokud píšete o Client Credentials Flow, tam zase nejsou dvě volání – hned prvním voláním dostanete Access Token. Redirect není proto, aby to mohl dělat backend – redirect je způsob, jakým se zpátky aplikaci, která zahájila přihlašování, předá řízení a hlavně jí předá údaje použitelné pro získání Access Tokenu.
-
Proč tedy ze supportu píšou "link pro přesměrování bude VOLÁN FAKTUROIDEM během autorizace". Nebo tím myslí "javascriptem fakturoidu běžícím v browseru"?
Na ten link bude Fakturoidem přesměrován prohlížeč uživatele.
Navíc jsem už psal že u mě teď žádný browser nehraje roli, vše se děje pomocí scriptů. Třeba výpisy se tahají schedulovaně na pozadí... "user" (token) je stále stejný (dokud exepiruje). Prostě necháput tu roli browseru v tom procesu, přece se to musí dát udělat nějak "neiteraktivně".
Role prohlížeče je ta, že přes něj se přihlásí uživatel Fakturoidu a udělí vám přístup. Na základě toho vám Fakturoid (při tom přesměrování) předá token, který budete používat pro přístup jménem toho uživatele.
Pokud to má být dlouhodobý přístup, možná ty tokeny budou dva – refresh token, který bude mít dlouho platnost a uživatel ho může zneplatnit, a ten pak v okamžiku komunikace vyměníte za access token, který bude mít platnost jen pár minut nebo možná hodin, a ten použijete teprve při samotném volání API.
Nainteraktivně to nejde, Fakturoid vám přece nemůže dát přístup k datům všech uživatelů. Musí tam být interakce uživatele, který schválí, že vaše aplikace má mít přístup k jeho údajům.
Neinteraktivne to pochopitelne v tomhle pripade take jde :). Jen misto jednoho curlu to budou dva. V jednom dostanete code a ten pak ten vymenite za access token. Na redirect se vyprdnete, resp. musite ho specifikovat kdyz zadate o code. Je to dano tim ze vsechny endpointy (jak pro code, tak i pro exchange code/tokeny jsou verejne dostupne). Ten redirect je pouze pro to, aby to moh delat backend. Coz ale v tomhle pripade neni ten scenar kterej tazatel chce.
Teď úplně nerozumím, o čem píšete. O kterém flow vlastně píšete. V případě Authorization Code Flow vám cUrl nepomůže, protože tam se musí uživatel v prohlížeči autentizovat a může to dělat třeba pomocí biometrie. Pokud píšete o Client Credentials Flow, tam zase nejsou dvě volání – hned prvním voláním dostanete Access Token. Redirect není proto, aby to mohl dělat backend – redirect je způsob, jakým se zpátky aplikaci, která zahájila přihlašování, předá řízení a hlavně jí předá údaje použitelné pro získání Access Tokenu.
A jakym stylem se tedy uzivatel overi a ziska code ? Samozrejme requestem na endpoint idp (viz treba prihlaseni na google/fb apod a integrace s vlastni aplikaci nebo manage identity v ramci azure). IdP samozrejme muze vyzadovst i nejakej jine mechanismy jako biometrii nebo 2fa ale neni to podminkou, zalezi jak mate nakonfigurovaneho klienta na idp. Pak vam nic nebrani ziskat code curlem a nasledne jinym curlem ziskat token.
-
jinak dve volani v ramci credentials codeflow sem myslel volani navic oproti stavu ktere ma tazatel ted. (musi ziskat token, s tokenem jde na endpoint oproti volam endpoint api klicem)
-
https://support.okta.com/help/s/article/How-to-get-tokens-for-an-OIDC-application-without-a-browser-using-curlPostman?language=en_US
-
A jakym stylem se tedy uzivatel overi a ziska code ?
U typu authorization code grant se uživatel se ověří tak, jak požaduje autorizační server. Jménem a heslem, otiskem prstu, privátním klíčem na tokenu – to je jedno. To řeší autorizační server. Code uživatel nezíská. Získá ho prohlížeč po přesměrování, ten ho předá backendu a backend ho pak vymění za token. Je to proto, aby prohlížeč nemusel znát token a ten zůstal jen na backendu – pokud existuje backend. Pokud backend neexistuje nebo má/může token znát i frontend, vymění code za token frontend.
Pak vam nic nebrani ziskat code curlem a nasledne jinym curlem ziskat token.
Authorization code se dělá proto, aby klient (=aplikace) neznal uživatelovy přihlašovací údaje. Pokud budete uvažovat speciální případ, kdy uživatel používá svého klienta (třeba cUrl), takže mu svěří přístupové údaje, můžete to samozřejmě volat pomocí cUrl – můžete z něj zavolat vše, co posílá prohlížeč. Akorát simulovat třeba přihlášení ke Googlu pomocí Passkey pomocí cUrl bych asi nechtěl.
-
aaa jasny, nevsim sem si ze ten odkaz na ten POST v fakturuid dokumentaci pro cloent credentials je klikaci a je tam priklad kde maj bejt jaky hodnoty. Bohuzel ted nejsem u pocitace, zkuste to sam a kdyby to neslo pastnu to vecer
Tak jsem se v těch složenejch zavorkach, jednoduchejch a dvojitejch uvozovkach dočista ztratil, furt mi to píše hlášku o invalidním JSON :-/
Mohl bych vas tedy poprosit o ukazku spravneho formatovani? moc díky!
-
https://www.fakturoid.cz/api/v3/authorization#client-credentials-flow
To je ale použitelné jedině v případě, kdy jeden uživatel používá svou aplikaci, které důvěřuje a které je ochoten dát své přístupové údaje k Fakturoidu. O tom, že by to byla takováto soukromá aplikace, nebyla nikde v dotazu řeč. Ale je pravda, že to dotaz ani nevylučuje.
Ano, je to soukromé hejno shell scriptů kterým plně důvěřuji.
-
aaa jasny, nevsim sem si ze ten odkaz na ten POST v fakturuid dokumentaci pro cloent credentials je klikaci a je tam priklad kde maj bejt jaky hodnoty. Bohuzel ted nejsem u pocitace, zkuste to sam a kdyby to neslo pastnu to vecer
Tak jsem se v těch složenejch zavorkach, jednoduchejch a dvojitejch uvozovkach dočista ztratil, furt mi to píše hlášku o invalidním JSON :-/
Mohl bych vas tedy poprosit o ukazku spravneho formatovani? moc díky!
curl -X POST "https://app.fakturoid.cz/api/v3/oauth/token" -H "Content-Type: application/json" -H "Authorization: Basic <BASE64 client_id:client:secret>" -H "Accept: application/json" --data '{"grant_type": "client_credentials"}' -v
# Do authorizacni hlavicky prijde vystup z tohoto prikazu:
echo "$client_id:$client_secret" | base64
Je to bez zaruky - fakturuid nepouzivam ale vypada to cajk:
$ curl -X POST "https://app.fakturoid.cz/api/v3/oauth/token" -H "Content-Type: application/json" -H "Authorization: Basic bXVqY2xpZW50Om1vanNlY3JldAo=" -H "Accept: application/json" --data '{"grant_type": "client_credentials"}' -v
Note: Unnecessary use of -X or --request, POST is already inferred.
* Trying 174.138.100.186...
* TCP_NODELAY set
* Connected to app.fakturoid.cz (174.138.100.186) port 443 (#0)
.
> POST /api/v3/oauth/token HTTP/1.1
> Host: app.fakturoid.cz
> User-Agent: curl/7.64.1
> Content-Type: application/json
> Authorization: Basic <BASE64 client_id:client:secret>
> Accept: application/json
> Content-Length: 36
>
* upload completely sent off: 36 out of 36 bytes
< HTTP/1.1 401 Unauthorized
.
.
* Connection #0 to host app.fakturoid.cz left intact
{"error":"invalid_client"}* Closing connection 0
-
aaa jasny, nevsim sem si ze ten odkaz na ten POST v fakturuid dokumentaci pro cloent credentials je klikaci a je tam priklad kde maj bejt jaky hodnoty. Bohuzel ted nejsem u pocitace, zkuste to sam a kdyby to neslo pastnu to vecer
Tak jsem se v těch složenejch zavorkach, jednoduchejch a dvojitejch uvozovkach dočista ztratil, furt mi to píše hlášku o invalidním JSON :-/
Mohl bych vas tedy poprosit o ukazku spravneho formatovani? moc díky!
curl -X POST "https://app.fakturoid.cz/api/v3/oauth/token" -H "Content-Type: application/json" -H "Authorization: Basic <BASE64 client_id:client:secret>" -H "Accept: application/json" --data '{"grant_type": "client_credentials"}' -v
# Do authorizacni hlavicky prijde vystup z tohoto prikazu:
echo "$client_id:$client_secret" | base64
Je to bez zaruky - fakturuid nepouzivam ale vypada to cajk:
$ curl -X POST "https://app.fakturoid.cz/api/v3/oauth/token" -H "Content-Type: application/json" -H "Authorization: Basic bXVqY2xpZW50Om1vanNlY3JldAo=" -H "Accept: application/json" --data '{"grant_type": "client_credentials"}' -v
Note: Unnecessary use of -X or --request, POST is already inferred.
* Trying 174.138.100.186...
* TCP_NODELAY set
* Connected to app.fakturoid.cz (174.138.100.186) port 443 (#0)
.
> POST /api/v3/oauth/token HTTP/1.1
> Host: app.fakturoid.cz
> User-Agent: curl/7.64.1
> Content-Type: application/json
> Authorization: Basic <BASE64 client_id:client:secret>
> Accept: application/json
> Content-Length: 36
>
* upload completely sent off: 36 out of 36 bytes
< HTTP/1.1 401 Unauthorized
.
.
* Connection #0 to host app.fakturoid.cz left intact
{"error":"invalid_client"}* Closing connection 0
Tak už hlásí jen Invalid client
* We are completely uploaded and fine
* Connection state changed (MAX_CONCURRENT_STREAMS == 1024)!
< HTTP/2 401
< cache-control: no-store
< content-length: 26
< content-type: application/json; charset=utf-8
< pragma: no-cache
< referrer-policy: strict-origin-when-cross-origin
< strict-transport-security: max-age=63072000; includeSubDomains; preload
< vary: Accept-Encoding,Accept
< www-authenticate: Basic xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
< x-content-type-options: nosniff
< x-frame-options: SAMEORIGIN
< x-permitted-cross-domain-policies: none
< x-request-id: b33c4ac2-8035-4aa9-94d9-cb9d9e20c942
< x-runtime: 0.005270
< x-xss-protection: 0
< date: Fri, 12 Apr 2024 10:57:28 GMT
< alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400
<
* Connection #0 to host app.fakturoid.cz left intact
{"error":"invalid_client"}
-
... a davate tam to client_id a client_secret z toho user menu a ne z auth code flow menu, ze jo ?
Before you start go to your Fakturoid account and download your Client ID and Client Secret from your user screen Settings → User account.
pokud jo, taak podporaa :)
-
... a davate tam to client_id a client_secret z toho user menu a ne z auth code flow menu, ze jo ?
Before you start go to your Fakturoid account and download your Client ID and Client Secret from your user screen Settings → User account.
neměl jsem, ale ani po výměně to nechodí. Jdu na podporu, každopádně MOC díky.
BTW: Chápu to správně že tenhle curl by mi měl vrátit TOKEN kterým pak autentizuju ten vlastní požadavek?
-
ano, mel byste dostat neco jako:
{
"access_token": "26e53aa3244b4c0aed56cb54a0223484e9c4aea49b09a03e4600ba995811b6af06428afc223c4c0c",
"token_type": "Bearer",
"expires_in": 7200
}
access token vypreparujete nakym awk nebo jq a pouzijete v Authorization hlavicce pri api requestech
-
ano, mel byste dostat neco jako:
{
"access_token": "26e53aa3244b4c0aed56cb54a0223484e9c4aea49b09a03e4600ba995811b6af06428afc223c4c0c",
"token_type": "Bearer",
"expires_in": 7200
}
access token vypreparujete nakym awk nebo jq a pouzijete v Authorization hlavicce pri api requestech
Jsem zvyklej na Xidel, to bude hračka.
Každopádně ještě jednou díky....
-
v pohode, dejte jen vedet zda to chodi, myslim ze by se to hodilo i ostatnim.
-
Vypadá to na nějaký problém na straně Fakturoidu, protože to invalid_client a 401 hlásí i když je dotaz vytvořen přesně podle dokumentace nebo podle toho, jak by ho vytvořila jejich oficiální PHP knihovna.
-
Vypadá to na nějaký problém na straně Fakturoidu, protože to invalid_client a 401 hlásí i když je dotaz vytvořen přesně podle dokumentace nebo podle toho, jak by ho vytvořila jejich oficiální PHP knihovna.
Jojo, taky mi to nedalo, taky sem to zkousel a maj to rozbity :) - resp. tipuju ze v dokumentaci neco chybi
-
Tak nakonec token získám takto (testovací mašina jede na Win):
curl.exe -s "https://app.fakturoid.cz/api/v3/oauth/token" -H "Content-Type: application/json" -H "Authorization: Basic Mjk4... ...NDY0" -H "Accept: application/json" -d "{\"grant_type\": \"client_credentials\"}" | xidel.exe -s --input=- -e "access_token"
nerozchodil jsme to bez cURL protože Xidelu na Win nějak vadí dvojite uvozovky u POST dat, ale nijak moc jsme se s tím netrápil, to budu stejně ladit až nakonec na provozní mašině.
díky všem za pomoc!
-
To znamená, že client_id a client_secret mají být do BASE64 zakódované každé zvlášť a oddělené mezerou?
To by si to mohli opravit v dokumentaci a v referenční implementaci v PHP…
-
To znamená, že client_id a client_secret mají být do BASE64 zakódované každé zvlášť a oddělené mezerou?
To by si to mohli opravit v dokumentaci a v referenční implementaci v PHP…
tady je to popsané, jen mi trvalo zjistit že ten poslední zelený obdélníček POST je průklik k detailu :-/
https://www.fakturoid.cz/api/v3/authorization#client-credentials-flow
-
tady je to popsané, jen mi trvalo zjistit že ten poslední zelený obdélníček POST je průklik k detailu :-/
https://www.fakturoid.cz/api/v3/authorization#client-credentials-flow
Tam je právě napsané, že se to posílá jako standardní BASIC autentizace, client_id se použije jako jméno a client_secret jako heslo. Přičemž tahle varianta mi nefungovala, a vám podle všeho také ne.
-
tady je to popsané, jen mi trvalo zjistit že ten poslední zelený obdélníček POST je průklik k detailu :-/
https://www.fakturoid.cz/api/v3/authorization#client-credentials-flow
Tam je právě napsané, že se to posílá jako standardní BASIC autentizace, client_id se použije jako jméno a client_secret jako heslo. Přičemž tahle varianta mi nefungovala, a vám podle všeho také ne.
Ano, má tam být Bearer místo Basic
-
Pořád tedy není jasné, jak má ten požadavek vypadat, aby ta autentizace prošla. Uvedl jste nějaký příklad, ze kterého ale není jasné, jak má autentizační hlavička vzniknout. Navíc tam máte použitou autentizaci Basic, pak ale píšete, že se má použít Bearer.
-
Pořád tedy není jasné, jak má ten požadavek vypadat, aby ta autentizace prošla. Uvedl jste nějaký příklad, ze kterého ale není jasné, jak má autentizační hlavička vzniknout. Navíc tam máte použitou autentizaci Basic, pak ale píšete, že se má použít Bearer.
tohle je funkční výpis faktur po splatnosti (zatim jen na testovací Win mašině)
powershell.exe "[convert]::ToBase64String([Text.Encoding]::UTF8.GetBytes(\"%client_id%:%client_secret%\"))"
for /f "tokens=*" %a in ('curl.exe -s "https://app.fakturoid.cz/api/v3/oauth/token" -H "Content-Type: application/json" -H "Authorization: Basic Mjk4Z... ...zNDY0" -H "Accept: application/json" -d "{\"grant_type\": \"client_credentials\"}" ^| xidel.exe -s --input=- -e "access_token"') do curl.exe -H "Content-Type: application/json" -H "Authorization: Bearer %a" -H "Accept: application/json" "https://app.fakturoid.cz/api/v3/accounts/...SLUG.../invoices.json?status=overdue"
BTW: Pokud se vyřeší eskejpování dvojuvozovek v shellu, lze vypustit ten cURL
-
Pokud by používali skutečnou BASIC autentizaci, kde by client_id bylo uživatelské jméno a client_secret heslo, pak není potřeba řešit nějaké ruční kódování hlavičky, BASIC autentizaci umí i curl.
curl -X POST --location "https://app.fakturoid.cz/api/v3/oauth/token" \
-H "Content-Type: application/json" \
-H "Accept: application/json" \
-d '{"grant_type": "client_credentials"}' \
--basic --user $client_id:$client_secret
Akorát že takhle mi to nefunguje, pořád to vrací 401 a v JSONu invalid_client.