1. Fórum Root.cz
  2. Profil SamElanius
  3. Zobrazit příspěvky
  4. Příspěvky

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

Stran: [1]
1
Vývoj / Re:SW pro náhradu kódu
« kdy: 31. 05. 2019, 22:35:14 »
Zmeny API ve vasem pripade mohou byt dvojiho typu:
1. zmena logiky - zde vam sebelepsi nastroj nepomuze. Pokud API dava neco jineho, stejne musite prepracovavat alespon castecne business a DB vrstvu.
2. zmena nazvu - pokud opravdu jde jen o kosmeticke zmeny nazvu metod/promenych na API a Vam to vyvolava chyby v business logice, pak mate spatne navrzenou aplikaci. Musite mit mezivrstvu, ktera dane api abstrahuje. Priklad: Pokud mapuji API nejakou datovou tridou, pak nelze tuto datovou tridu pouzivat v businessu, musite mit 2 tridy (byt na zacatku vyvoje jsou totozne) a premapovavat mezi nimi. Nedejboze aby jste pouzival stejnou tridu na mapovani API a jako entitu v DB.

2
Sítě / Re:Mitmproxy posílá požadavky zpět na klienta
« kdy: 22. 03. 2019, 17:50:54 »
Souhlasim. Zkusil jsem wget na stroji mimo proxy, a stejne chovani. Proste spatny vyber testovaciho vzorku, root.cz to nedela :D Velice dekuji za pomoc, tohle by me nenapadlo. V pondeli to zkusim nasadit na cilovy system.

3
Sítě / Re:Mitmproxy posílá požadavky zpět na klienta
« kdy: 22. 03. 2019, 17:03:41 »
Kód: [Vybrat]
DEBUG output created by Wget 1.18 on linux-gnu.

Reading HSTS entries from /root/.wget-hsts
URI encoding = 'ANSI_X3.4-1968'
converted 'https://seznam.cz' (ANSI_X3.4-1968) -> 'https://seznam.cz' (UTF-8)
Converted file name 'index.html' (UTF-8) -> 'index.html' (ANSI_X3.4-1968)
--2019-03-22 17:01:29--  https://seznam.cz/
Certificates loaded: 152
Resolving seznam.cz (seznam.cz)... 77.75.77.39, 77.75.77.53, 77.75.79.39, ...
Caching seznam.cz => 77.75.77.39 77.75.77.53 77.75.79.39 77.75.79.53 2a02:598:2::1053 2a02:598:a::79:39 2a02:598:a::79:53 2a02:598:2::1039
Connecting to seznam.cz (seznam.cz)|77.75.77.39|:443... connected.
Created socket 3.
Releasing 0x0000564eedfaca80 (new refcount 1).

---request begin---
GET / HTTP/1.1
User-Agent: Wget/1.18 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: seznam.cz
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 302 Moved Temporarily
Server: nginx
Date: Fri, 22 Mar 2019 16:01:29 GMT
Content-Type: text/html
Content-Length: 154
Connection: keep-alive
Location: https://www.seznam.cz/

---response end---
302 Moved Temporarily
Registered socket 3 for persistent reuse.
Location: https://www.seznam.cz/ [following]
Skipping 154 bytes of body: [<html>
<head><title>302 Found</title></head>
<body bgcolor="white">
<center><h1>302 Found</h1></center>
<hr><center>nginx</center>
</body>
</html>
] done.
URI content encoding = None
converted 'https://www.seznam.cz/' (ANSI_X3.4-1968) -> 'https://www.seznam.cz/' (UTF-8)
Converted file name 'index.html' (UTF-8) -> 'index.html' (ANSI_X3.4-1968)
--2019-03-22 17:01:29--  https://www.seznam.cz/
Resolving www.seznam.cz (www.seznam.cz)... 77.75.77.53, 77.75.79.39, 77.75.79.53, ...
Caching www.seznam.cz => 77.75.77.53 77.75.79.39 77.75.79.53 77.75.77.39 2a02:598:a::79:53 2a02:598:2::1039 2a02:598:2::1053 2a02:598:a::79:39
Connecting to www.seznam.cz (www.seznam.cz)|77.75.77.53|:443... connected.
Created socket 4.
Releasing 0x0000564eee35f5f0 (new refcount 1).

---request begin---
GET / HTTP/1.1
User-Agent: Wget/1.18 (linux-gnu)
Accept: */*
Accept-Encoding: identity
Host: www.seznam.cz
Connection: Keep-Alive

---request end---
HTTP request sent, awaiting response...
---response begin---
HTTP/1.1 200 OK
Server: nginx
Date: Fri, 22 Mar 2019 16:01:29 GMT
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding
Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
X-Frame-Options: SAMEORIGIN
Content-Security-Policy: frame-ancestors 'self'
Content-Encoding: gzip

---response end---
200 OK
Disabling further reuse of socket 3.
Registered socket 4 for persistent reuse.
URI content encoding = 'UTF-8'
Length: unspecified [text/html]
Saving to: 'index.html'

4
Sítě / Re:Mitmproxy posílá požadavky zpět na klienta
« kdy: 22. 03. 2019, 15:33:32 »
I v dokumentaci je ze http i https se smeruje na jeden port a ze se nepridava zadny prepinac jestli to ma byt http/https proxy. Z toho mi plyne, ze by mel zvladat oboje ale tento zapis je trochu zavadejici.

V systemu aktualne neni vyexportovane ani HTTP_PROXY ani HTTPs_PROXY.

Na proxyserveru (tam kde je mitmproxy abych byl presnejsi) jsem udelal jen to co je popsano zde https://docs.mitmproxy.org/stable/howto-transparent/.

Nicmene dokud jsem nenaimportovat certifikat tak wget hlasil nevalidni cert. Tzn. asi to po https pujde.


5
Sítě / Re:Mitmproxy posílá požadavky zpět na klienta
« kdy: 22. 03. 2019, 14:54:03 »
Anticomp nepomohl. Pridavam vypisy z clienta i proxy:
Kód: [Vybrat]
root@xxxxx:/opt/test# wget https://seznam.cz
\--2019-03-22 14:49:21--  https://seznam.cz/
Resolving seznam.cz (seznam.cz)... 77.75.77.53, 77.75.79.39, 77.75.79.53, ...
Connecting to seznam.cz (seznam.cz)|77.75.77.53|:443... connected.
HTTP request sent, awaiting response... 302 Moved Temporarily
Location: https://www.seznam.cz/ [following]
--2019-03-22 14:49:22--  https://www.seznam.cz/
Resolving www.seznam.cz (www.seznam.cz)... 77.75.79.53, 77.75.77.39, 77.75.77.53, ...
Connecting to www.seznam.cz (www.seznam.cz)|77.75.79.53|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [text/html]
Saving to: 'index.html.5'

index.html.5                                                    [ <=>                                                                                                                                      ]  50.45K  --.-KB/s    in 0s

2019-03-22 14:49:22 (99.7 MB/s) - 'index.html.5' saved [51663]


Kód: [Vybrat]
xxx:~ xxx$ mitmproxy --mode  transparent --showhost --anticomp
Proxy server listening at http://*:8080
10.0.10.60:55162: clientconnect
10.0.10.60:55162: GET https://seznam.cz/
               << 302 Moved Temporarily 154b
10.0.10.60:48746: clientconnect
10.0.10.60:48746: GET https://www.seznam.cz/
               << 200 OK 50.45k
10.0.10.60:55162: clientdisconnect
10.0.10.60:48746: clientdisconnect

obsah souboru (od zacatku nekolik radek):
Kód: [Vybrat]
�[s�.�>�"
e5��aH��j�II%�nQŮQo�$y�T�$���z��e�p^�Vk��5�c�Y�ټ�5� �H��u��L$�o"Q�D������H���_�}����6�n`[w�)I���L�X�ٻ]���,��
                                                                                                            ��8\��$�k�7��[�����	��.��W�[���$��h]��,��]�U �yF`�;[l�P�(ġ==$�W�Ɖ����%�kN��n�
=���YdhL_V���A-�ר�n�+ĆB�d��v!2�k�{�(>�|�Kg��n`p'C�S�sh4��E<��ѻ��`��e�9��sX�#�
�F����AD�ޮ��԰5��:�a�z�B��/Lwyt���?����ԇǔpݤxnB]���g��]�.׍�8�k�U�u-C��*S2M��[��X�c�Y ���`H�c�(��믖J�_�.�I	�i`�����)�~�]/W��F�	|���6>ϭ�$))�L7hɰ�J��2��v�J�u�
��˼����VA^��o����.�F�#�?�U�t`���n����BϺ]
?tQJ��t<��g^��#stc�O�r��F�_q�bh]��!�z~/g_��h�G����ӧ/ϼ�.��م�'��/�h���bK;�NOˮ�ٟ�A]�q�����}v6�|2|�e>��
                                                                                                  �y�-���)�g�Ӻ 3���
                                                                                                                   ��/ɷx��

6
Sítě / Re:Mitmproxy posílá požadavky zpět na klienta
« kdy: 22. 03. 2019, 13:23:09 »
Zdravim,
opravdu byla chyba v architekture presmerovani. Tu jsem aktualne zmenil, ale mam jiny problem.
Nyni mam na odposlouchavanem serveru nastaveny proxyserver jako vychozi branu (z dokumentace to je ten prvni pripad u transparent proxy) a mam i importovane certifikaty. A nyni:
1. udelam wget na zabezpecenou stranku
2. proxy odposlechne a prebali komunikaci - na proxy vidim obsah dotazu i odpovedi
3. wget nenahlasi problem s certifikatem - vse se tvari ok
4. ALE wget stahne rozsypany caj (mozna nejak zasifrovanou komunikaci)

jedu presne podle manualu. Zkousel jsem to na 2 verzich mitmproxy (na dvou ruznych strojich) a na obou stejne.

7
Sítě / Mitmproxy posílá požadavky zpět na klienta
« kdy: 18. 03. 2019, 11:18:59 »
Zdravim,
zkousim si pouziti mitmproxy. Infrastruktura vypada takto:
Client - odposlouchavany odesila pozadavky na http do internetu
router odklani jeho pozadavky na proxy server (rovnou smeruje na port 8080, na serveru tedy nejsou pravidla pro preposilani z 80/433 -> 8080)
proxy server - zde je nainstalovany mitmproxy a spusteny v transparentnim modu.

Problemem je to, ze proxy prijme pozadavek od klienta, ale misto toho aby udelala ten samy pozadavek na cilovou adresu, odesle udela ho na zdrojoveho klienta (ten samozrejme nema vystavenou 80 -> okamzite refuse -> proxy vrati na puvodni pozadavek 402).

Nemate predstavu kde by mohl byt problem? Dekuji

8
Vývoj / Re:PayU - Nelze vytvořit novou platbu
« kdy: 11. 04. 2014, 09:58:52 »
Ja se s PayU silene vyvztekal. Jejich dokumentace je v urcitejch mistech dost nepresna a v ukazkovym skriptu meli taky chyby. A nejhorsi je technicka podpora kde nejspis vsechny dotazy jen prekladaji do polstiny a odesilaji...

9
Server / Re:Využití domácího serveru
« kdy: 04. 04. 2014, 23:08:35 »
Ale podle toho co rika o "12 hlavnich databazich" a o tom ze vetsinu casu programuje, tak ho my lamy vubec nechapem... On chce naprogramovat DNS a DHCP servery a pak je pouzivat nebo nekomu strelit :D

Stran: [1]