Příspěvky

61

Vývoj / MariaDB - synchronizace DB schématu test/prod

« kdy: 07. 09. 2021, 16:35:13 »

Synchronizaci db schématu z testu do produkce provádím pomocí skriptu, který provádí všechny změny a zajišťuje, že schéma je ve verzi, která je v produkci očekávána. Skript obsahuje všechny příkazy pro aktualizaci schématu.
Někdy hrábnu do schématu pomocí phpMyAdmin a zapomenu změnu provést do skriptu pro aktualizaci schématu.
Existuje nějaké řešení jak exportovat pouze schéma, importovat ho do jiné databáze a zachovat existující data?

62

Server / Re:React router + Apache

« kdy: 07. 09. 2021, 16:19:14 »

Tak chybějící přísada byla: "basename"

Kód: [Vybrat]

https://reactrouter.com/web/api/BrowserRouter

Nastavení serveru:

Kód: [Vybrat]

#DEMO only
<Directory "/data/product_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]

63

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]

64

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

65

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.

66

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.

67

Hardware / Re:WIFI: Jak funguje příjem a vysílaní současně jednou anténou

« kdy: 25. 08. 2021, 17:02:34 »

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í?

68

Hardware / WIFI: Jak funguje příjem a vysílaní současně jednou anténou

« kdy: 25. 08. 2021, 15:38:50 »

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.

69

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

70

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.

71

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?

72

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

73

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.

74

Vývoj / Re:PHP - mikroslužby - autentizace

« kdy: 02. 08. 2021, 10:38:53 »

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.

75

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