Příspěvky

1

Studium a uplatnění / Re:Ako fungujete na HO v spojení s rodinou?

« kdy: 14. 10. 2024, 20:51:39 »

Mam tri velmi male deti (5let + 2x11 mesicu) a jezdim do coworku. Doma se to neda i kdyz mam mistnost jen pro sebe a i kdyz mam velmi hodne deti i velmi hodnou zenu . Bohuzel muj mozek ma zafizovan vzorec “deti >> prace”, takze pri sebemensim audio sumu pripominajici plac ci detskou nelibost je moje soustredeni v haji.

Cowork mam za rohem, neresim dopravni zacpy, deti, kolegy a je to vlastne idealni stav.

2

/dev/null / Re:sgi, sun, hp, next

« kdy: 20. 04. 2024, 22:36:40 »

yep, mel sem doma AlphaStation 200, pak sgi indigo a nakou parisc wks - ani u jednoho uz si nepamatuju typ. Ta Alpha byla docela pouzitelna a par firem co meli treba True Clustery jsme spravovali. A pak samozrejme pSeries od ibmky (powery jedou defacto do dnesnich dni)

3

Hardware / Re:Konkrétní výhody starých enterprise serverů

« kdy: 19. 04. 2024, 07:26:41 »

Jak uz tu zaznelo:
- moznost osahat si enterprise technologie
- spolehlivy hardware, casto hotplug a vymenitelnost komponent
- lepsi podpora driveru
- robustnejsi architektura (rychly procesor neni vse)

Jinak  s tou hlucnosti a spotrebiu to mnohdy neni tak zle, zalezi na rade, vendorovi a zatezi samozrejme. Zkratka na lab je to idealni vec, na domaci provoz 24x7 to nedoporucuji .

4

Sítě / Re:OAuth a potřeba veřejné IP adresy

« kdy: 14. 04. 2024, 22:18:21 »

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

5

Sítě / Re:OAuth a potřeba veřejné IP adresy

« kdy: 12. 04. 2024, 18:46:01 »

v pohode, dejte jen vedet zda to chodi, myslim ze by se to hodilo i ostatnim.

6

Sítě / Re:OAuth a potřeba veřejné IP adresy

« kdy: 12. 04. 2024, 15:34:24 »

ano, mel byste dostat neco jako:

Kód: [Vybrat]

{
  "access_token": "26e53aa3244b4c0aed56cb54a0223484e9c4aea49b09a03e4600ba995811b6af06428afc223c4c0c",
  "token_type": "Bearer",
  "expires_in": 7200
}
access token vypreparujete nakym awk nebo jq a pouzijete v Authorization hlavicce pri api requestech

7

Sítě / Re:OAuth a potřeba veřejné IP adresy

« kdy: 12. 04. 2024, 13:21:37 »

... 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

8

Sítě / Re:OAuth a potřeba veřejné IP adresy

« kdy: 12. 04. 2024, 12:25:11 »

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:

Kód: [Vybrat]

$ 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

9

Bazar / Re:Prodám diskové pole HP MSA 2040

« kdy: 12. 04. 2024, 08:23:26 »

Za ty prachy můžu mít dneska stejnou kapacitu na SSD...

Pane GPU, lide si takove veci nekupuji kvuli kapacite, ale aby si osahali enterprise technologie a neco se naucili.

Ja bych treba zajem mel, jen ne ted a ne za tuto cenu

10

Sítě / Re:OAuth a potřeba veřejné IP adresy

« kdy: 11. 04. 2024, 20:04:12 »

https://support.okta.com/help/s/article/How-to-get-tokens-for-an-OIDC-application-without-a-browser-using-curlPostman?language=en_US

11

Sítě / Re:OAuth a potřeba veřejné IP adresy

« kdy: 11. 04. 2024, 19:53:30 »

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)

12

Sítě / Re:OAuth a potřeba veřejné IP adresy

« kdy: 11. 04. 2024, 19:51:42 »

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.

13

Sítě / Re:OAuth a potřeba veřejné IP adresy

« kdy: 11. 04. 2024, 18:53:14 »

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.

14

Sítě / Re:OAuth a potřeba veřejné IP adresy

« kdy: 11. 04. 2024, 18:31:38 »

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.

15

Sítě / Re:OAuth a potřeba veřejné IP adresy

« kdy: 11. 04. 2024, 15:17:57 »

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