Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - vesterna12

Stran: 1 [2] 3 4 5
16
Server / Re:React router + Apache
« kdy: 04. 09. 2021, 18:22:26 »
Kód: [Vybrat]
DocumentRoot "/data/software_demo/public"
<Directory "/data/software_demo/public">
    AllowOverride All
    Require all granted
</Directory>


<Directory "/data/software_demo/public/frontend/admin/build">

 RewriteEngine on
    RewriteCond %{REQUEST_FILENAME} -f [OR]
    RewriteCond %{REQUEST_FILENAME} -d
    RewriteRule ^ - [L]
  RewriteRule ^ /frontend/admin/build/index.html [L]
</Directory>

RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !(\.css|\.js|\.png|\.jpg|\.jpeg|\.gif)$ [NC]
RewriteCond %{REQUEST_URI} !^/frontend/admin/build
RewriteRule ^(.*)$ /index.php?$1 [NC,L,QSA]



17
Server / Re:React router + Apache
« kdy: 04. 09. 2021, 17:53:16 »
Nahradil jsem Location -> <Directory> , ale bez výsledku.
Pří dotazu /frontend/admin/build/home sice dostanu 200 návratový kód, ale stránka není vykreslená (stavová komponenta v Reactu nahraná pomocí R. Router). Pokud to mám puštěné pomocí "npm start" tak tam to funguje jak má.
Package json je  "homepage": "http://localhost:6060/frontend/admin/build" nastavená taky správně.


18
Server / React router + Apache
« kdy: 04. 09. 2021, 13:35:18 »
Nefunguje mi aplikce psaná v Reactu používající React Router která není v "kořenu" serveru.

/index.php je používaný jinou aplikací.
/frontend/admin/build je aplikace Reactu. Titulní stránku dostanu, ale pokud se pokusím dostat na jinou komponentu (/frontend/admin/build/home) pomocí React Router tak se stránka nevykreslí.

Používám následující konfiguraci Apache:


Kód: [Vybrat]

<Location "/frontend/admin/build">

 RewriteEngine on
    RewriteCond %{REQUEST_FILENAME} -f [OR]
    RewriteCond %{REQUEST_FILENAME} -d
    RewriteRule ^ - [L]
  RewriteRule ^ /frontend/admin/build/index.html [L]
</Location>


RewriteEngine on
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !(\.css|\.js|\.png|\.jpg|\.jpeg|\.gif)$ [NC]
RewriteCond %{REQUEST_URI} !^/frontend/admin/build
RewriteRule ^(.*)$ /index.php?$1 [NC,L,QSA]



Vše co není /frontend/admin/build je přesměrováno na index.php. Pokud  je v cestě  /frontend/admin/build pak je vše směrováno na  /frontend/admin/build pro který by měl platit <Location "/frontend/admin/build"> což funguje, ale při dotazu /frontend/admin/build/home vidím pořád titulní stánku.


19
Vývoj / SMS brána použitelná v Linuxu
« kdy: 25. 08. 2021, 22:25:30 »
Doporučil by někdo SMS bránu, kterou lze používat v Linuxu?
Používal jsem dřív gnokii v kombinaci s nějakým USB modemem. Rozchodit to nebylo úplně snadné a znovu bych se do toho nepustil. Jako náhradní řešení bych použil starý telefon s Androidem a napsal si jednoduchou apku pro příjem a odesílání SMS. Existující služby na webu používat nechci.

20
Tak pokud by WIFI přepínala mezi příjmem a vysílání, jak zjistí klient kdy je ten vhodný okamžik k vysílání?

21
Jak se nazývá technika, která umožňuje vysílat i přijímat signál ve stejném okamžiku pomocí jedné antény? Například jako u wifi.

22
Vývoj / Re:PHP - deserializace objektu - ošetření vstupu
« kdy: 08. 08. 2021, 13:24:57 »
Chtěl jsem se vyhnout replikaci relací.
Uživatel měl předložit podepsanou instanci objektu, která obsahuje info o autorizaci a autentizaci.
Teď jsem si na tom pěkně vylámal zuby.
Buď budu muset nastavit replikaci nebo objekty ukládat do db a získávat je zpět pomocí id uloženého v cookie...

23
Vývoj / Re:PHP - deserializace objektu - ošetření vstupu
« kdy: 08. 08. 2021, 12:24:11 »
Potřebuji předat instanci objektu do COOKIE, ale nevím jak to udělat jinak.

24
Vývoj / PHP - deserializace objektu - ošetření vstupu
« kdy: 08. 08. 2021, 12:06:42 »
Pomoci sha1 a serialize vytvarim hash instance objektu User.
Instance objektu je ulozena v COOKIE pomoci base64_encode.
Pomoci
Kód: [Vybrat]
unserialize(base64_decode($_COOKIE['user']),["allowed_classes" => ["User"]]); ; ziskavam objekt zpet a kontroluji jeho integritu znovu pomoci sha1 serialize.
Cetl jsem par clanku a ocividne to neni bezpecne, protoze deserialize methoda je snadno napadnutelna.
Muzu nejak vic ochranit unserialize metodu?

25
Vývoj / Re:PHP - mikroslužby - autentizace
« kdy: 02. 08. 2021, 13:40:28 »
Všechny komponenty dostanou certifikát generovaný z klíče. Nevadí, že si někdo stáhne certifikát a řetězec dešifruje, protože neobsahuje nic citlivého.
Pro demonstraci:

Kód: [Vybrat]
<?php

// Encryption

   
$data 'encryption test';
   
openssl_private_encrypt ($data$crypted file_get_contents('key.pem'),OPENSSL_PKCS1_PADDING);


// Decryption

   
openssl_public_decrypt($crypted $output file_get_contents('cert.pem2'),OPENSSL_PKCS1_PADDING );


echo 
$output;


?>



Pokud se komponentně nepovede dešifrování je zdroj podepsaný někým jiným. Konec 403...


26
Vývoj / Re:PHP - mikroslužby - autentizace
« kdy: 02. 08. 2021, 11:10:38 »
Já vážně myslel šifrování. https://www.php.net/manual/en/function.openssl-public-decrypt.php
V tom případě budou opačně ty klíče – autorizační server bude šifrovat veřejným klíčem, služby dešifrovat privátním. Správně by každá služba měla mít svůj privátní klíč. Ale počítejte s tím, že šifrovaná data nezaručují autenticitu. Tedy stejně bude potřeba je podepisovat.


V případě, že by se někdo upsal v ověřování podpisu a kód by správně neskončil, aplikace má pořád k dispozici výpis autorizace a mohla by teoreticky pokračovat i když je podpis neplatný. Pokud nedojde k dešifrování tak prostě nelze pokračovat, protože oprávnění jsou "null".
To mi připadá trošku překombinované. Když se neověří podpis, stejně nemůžete těm údajům věřit. A na to, že je nemohl zašifrovat nikdo jiný, se spoléhat nedá – šifruje se veřejným certifikátem, tj. musíte počítat s tím, že data může zašifrovat kdokoli. Bez ohledu na to, zda si budete hlídat, aby se veřejný certifikát nedostal „ven“.

Šifrovat řetězec můžu privátním klíčem a možné je ho dešifrovat pouze pomocí relevantního certifikátu generovaného z privátního klíče. Je to tak? Psal jsem klíče, ale myslel jsem klíč a certifikát. Pokud to tak je tak když se mi nepovede dešifrování certifikátem tak můžu považovat zdroj za nedůvěryhodný, protože byl šifrován očividně někým jiným.

27
Vývoj / Re:PHP - mikroslužby - autentizace
« kdy: 02. 08. 2021, 10:38:53 »
Citace
Chtěl bych aplikaci rozložit do několika mikroslužeb kvůli škálování

Pokud uvažujete o microservisní architektuře, je třeba nekoukat jen na výhody, ale přečíst si i nevýhody... Z osobní zkušenosti bych tutu architekturu doporučil pouze v případě, že

A) Máte velmi velký SW
B) Máte několik týmů o několika vývojářích

Ve většině případu platí A, ale už nikdo nemá/nezaplatí B... V pár lidech microservisní architektura přináší víc nevýhod než výhod.
  • Transakce, Rollback
  • Error handling
  • Autorizace/authentikace

  • Transakce, Rollback
- používám relační databázi
  • Error handling
- i v případě monolitu
  • Autorizace/authentikace
- to už tu teď řeším...

Aplikace není zase tak velká. Jde o jeden malý e-shop, ale je to skvělá příležitost a taky je tu potenciál růstu.

28
Vývoj / Re:PHP - mikroslužby - autentizace
« kdy: 02. 08. 2021, 10:30:44 »
Autentizační server jako jediný obsahuje privátní klíč, kterým šifruje data uvnitř COOKIE nebo JWT.
Každý koncový bod API pak dešifruje data pomocí veřejné části klíče.
Jenom pro přesnost, tohle je podepisování, ne šifrování. Šifrování by fungovalo opačně – to, co má být tajné se zašifruje veřejným klíčem, takže to následně může dešifrovat jen majitel privátního klíče. To, co vy potřebujete, je podepisování – takže postup jste popsal správně, jen se to jmenuje jinak. (Ano, na úrovni algoritmů je podepisování a šifrování to samé –  když po sobě provedete transformaci nejprve jedním a pak druhým klíčem z páru, dostanete zpět původní vstup.)
Já vážně myslel šifrování. https://www.php.net/manual/en/function.openssl-public-decrypt.php
V případě, že by se někdo upsal v ověřování podpisu a kód by správně neskončil, aplikace má pořád k dispozici výpis autorizace a mohla by teoreticky pokračovat i když je podpis neplatný. Pokud nedojde k dešifrování tak prostě nelze pokračovat, protože oprávnění jsou "null".

29
Vývoj / Re:PHP - mikroslužby - autentizace
« kdy: 01. 08. 2021, 15:16:32 »
Cílem je opustit kompletně php_session().
Chci co nejsnadnější škálování.
Možná Docker/Kubernetes, ale to mi přijde jako zbytečná další abstrakce (a spotřeba HW + další údržba). Automatizací posílám "Git release" na příslušné stroje. Stroje mám škálované pomocí skriptů. Do 10 minut je server vzhůru.
Replikace relací je další zbytečná komplikace.
Je vyloučeno, aby klient při každém dotazu posílal znovu jméno a heslo uložené v nějakém objektu.
Nechci ani cache autentizace a autorizace na koncových bodech api.
Co nejméně volání do DB,AD,Kafky,AMQ, nebo Redisu.
Žádné sdílené disky mezi servery. Výjimku mají pouze CDN segmenty.
Funkci si chystám tak aby byla schopná dotazování AD, protože jeden zdroj pravdy už mám. Jako druhý autentizační poskytovatel bude MYSQL databáze a poslední CURL volání do extérního systému.
Autentizační server jako jediný obsahuje privátní klíč, kterým šifruje data uvnitř COOKIE nebo JWT.
Každý koncový bod API pak dešifruje data pomocí veřejné části klíče. Pokud se klient pokusí data podvrhnout je vyloučeno data podepsat důvěryhodným klíčem (uložen na HSM), který má pouze autentizační server.
Autorita je chráněná. Jen tak si někdo certifikát nepodepíše...

Programuju příležitostně a nevěděl jsem jestli není moje teorie zastaralá.
Děkuji panu Jiráskovi za jeho trpělivost a vysvětlení.


30
Vývoj / Re:PHP - mikroslužby - autentizace
« kdy: 30. 07. 2021, 17:21:07 »
Čistě teoreticky. Útočník podvrhne DNS a přesměruje klienta na svůj server. Tam mu vnutí JS a k tomu tokenu se stejně dostane. Je to tak? To stejné platí o cookies. Klidně by tak mělo jít přečíst PHP_SESSION_ID.
Jedině kdyby klient kontroloval certifikační autoritu, která podepsala certifikát web serveru. Pak by útočník musel napadnout přímo server kde aplikace běží.
Pokud útočník ovládne doménu, nemáte jak se mu bránit – prohlížeč si bude myslet, že komunikuje s legitimním serverem a dovolí mu všechno – číst sessionStorage, bude mu odesílat cookies, dovolí vložit do formuláře uložená hesla.

Dneska už to ale reálně nebude fungovat přesměrováním DNS, protože jakýkoli rozumný web jede přes HTTPS s certifikátem od důvěryhodné certifikační autority. HTTP klienti certifikáty kontrolují, takže útočník, který by přesměroval přes DNS jednoho klienta, má smůlu. Pokud by se ovšem útočníkovi podařilo přesměrovat DNS globálně (nejspíš tak, že získá přístup do správy DNS příslušné domény), nechá si vygenerovat i důvěryhodný certifikát.

Inu přidaná hodnota sessionStorage vs cookie je pouze ta že token není odeslán při každém požadavku na doménu pokud není získán JS.
Správně?

Stran: 1 [2] 3 4 5