HTTP POST response_stack modositas request_stack analizalas utan, AnyPy proxy-val
Udv, lehetseges valahogyan HTTP POST metodus-nal response_stack AnyPy tipusu proxy-nak adatokat atadni a request_stack analizalasa utan? Mas szoval: a POST-ban erkezo kerestol fuggoen kellene valaszt generalnom a kliensnek. A POST-ban erkezo adat elore nem meghatarozhato, barmi lehet. A gondom (ha jol latom,) hogy a request_stack altal a self.session-t irva, a response_stack mar nem "latja" a self.session-on elvegzett modositasokat. https://lists.balabit.hu/pipermail/zorp/2008-July/000453.html Itt taltam erre vonatkozo tippet: " ... Now as I think of it, there's another possibility, which is somewhat simpler. The HTTP proxy is capable of reading the entire POST data before connecting to the server at all and storing it in a blob (more about blobs later). In this case the entire request together with the POST payload is fetched into memory, and after filtering it is sent to the server. This code path is activated if you set "self.rerequest_attempts" to something greater than zero. So if you set rerequest_attempts, your stacked proxy will start earlier than the server side connection is established. ... " Probalgattam ezt a sefl.rerequest_attempts=1-re allitani, de nem sok sikert ertem el vele. Ilyenkor mar bele sem fut a feldolgozas az altalam beallitott response_stack proxy-ba. Zorp version: Zorp 3.3.4 Revision: ssh+git://sasa@git.balabit//var/scm/git/zorp/zorp-core--mainline--3.3#master#881e162e4536a0ca69645482a9c4176b833238c7 Compile-Date: Jun 4 2009 14:17:43 Config-Date: 2009/06/04 Trace: off Debug: off IPOptions: off IPFilter-Tproxy: off Netfilter-Tproxy: on Linux22-Tproxy: off libzorpll 3.3.0.9 Revision: devel@balabit.hu--zorp-1/zorp-lib--mainline--3.3--patch-70 Compile-Date: May 27 2009 10:43:44 Trace: off MemTrace: off Caps: on Debug: off StackDump: off libzmisc 3.3.0.4 Revision: ssh+git://sasa@git.balabit//var/scm/git/zorp/libzmisc--mainline--3.3#master#5198413a1eb47ea3a292322c27a63b1a4d6dd3c8 Compile-Date: May 27 2009 10:45:14 Trace: on Debug: on Koszontem, Viktor
On Thu, 2009-06-25 at 13:39 +0200, Viktor Tuska wrote:
Udv,
lehetseges valahogyan HTTP POST metodus-nal response_stack AnyPy tipusu proxy-nak adatokat atadni a request_stack analizalasa utan?
Mas szoval: a POST-ban erkezo kerestol fuggoen kellene valaszt generalnom a kliensnek. A POST-ban erkezo adat elore nem meghatarozhato, barmi lehet.
A gondom (ha jol latom,) hogy a request_stack altal a self.session-t irva, a response_stack mar nem "latja" a self.session-on elvegzett modositasokat.
https://lists.balabit.hu/pipermail/zorp/2008-July/000453.html Itt taltam erre vonatkozo tippet:
self.session.http-n keresztul latod a http sajat session-jet, amibe ha a gyerek proxyban irsz latszani fog a HTTP-ben. Esetleges versenyhelyzetekre azert nem art felkeszulni (a gyerek masik szalban fut, mint a szulo)
"
... Now as I think of it, there's another possibility, which is somewhat simpler. The HTTP proxy is capable of reading the entire POST data before connecting to the server at all and storing it in a blob (more about blobs later). In this case the entire request together with the POST payload is fetched into memory, and after filtering it is sent to the server.
This code path is activated if you set "self.rerequest_attempts" to something greater than zero. So if you set rerequest_attempts, your stacked proxy will start earlier than the server side connection is established. ...
"
Probalgattam ezt a sefl.rerequest_attempts=1-re allitani, de nem sok sikert ertem el vele. Ilyenkor mar bele sem fut a feldolgozas az altalam beallitott response_stack proxy-ba.
gondolom a sefl itt eliras, es self-et akartal irni. a rerequest-nel a request_stack oldalon dolgozhatod fel a POST adatokat (hiszen azok a POST request payload-jaban erkeznek)
Zorp version: Zorp 3.3.4 Revision: ssh+git://sasa@git.balabit//var/scm/git/zorp/zorp-core--mainline--3.3#master#881e162e4536a0ca69645482a9c4176b833238c7 Compile-Date: Jun 4 2009 14:17:43 Config-Date: 2009/06/04 Trace: off Debug: off IPOptions: off IPFilter-Tproxy: off Netfilter-Tproxy: on Linux22-Tproxy: off
libzorpll 3.3.0.9 Revision: devel@balabit.hu--zorp-1/zorp-lib--mainline--3.3--patch-70 Compile-Date: May 27 2009 10:43:44 Trace: off MemTrace: off Caps: on Debug: off StackDump: off
libzmisc 3.3.0.4 Revision: ssh+git://sasa@git.balabit//var/scm/git/zorp/libzmisc--mainline--3.3#master#5198413a1eb47ea3a292322c27a63b1a4d6dd3c8 Compile-Date: May 27 2009 10:45:14 Trace: on Debug: on
-- Bazsi
Szia, koszi szepen mindjart kiprobalom ezt a self.session.http-t Valoban elirtam, nemcsak a self-et, de a request_stack-et is. Valojaban request_stack-el tesztelgettem a rerequest_attempts=1-el, de igy a POST-nal nem latom, hogy belefutna a kod a request_stack proxy-ba. self.request_stack["POST"] = (HTTP_STK_DATA, MagicSaverRequest) Ha nem definialom a rerequest_attempts-t, akkor meg belefut. Elkepzelheto, hogy user error van nalam. Az megoldhato elmeletileg, hogy a POST keres feldolgozasa utan a request_stack-ben modositom a request_url-t (redirect)? Udv, Viktor Balazs Scheidler wrote:
On Thu, 2009-06-25 at 13:39 +0200, Viktor Tuska wrote:
Udv,
lehetseges valahogyan HTTP POST metodus-nal response_stack AnyPy tipusu proxy-nak adatokat atadni a request_stack analizalasa utan?
Mas szoval: a POST-ban erkezo kerestol fuggoen kellene valaszt generalnom a kliensnek. A POST-ban erkezo adat elore nem meghatarozhato, barmi lehet.
A gondom (ha jol latom,) hogy a request_stack altal a self.session-t irva, a response_stack mar nem "latja" a self.session-on elvegzett modositasokat.
https://lists.balabit.hu/pipermail/zorp/2008-July/000453.html Itt taltam erre vonatkozo tippet:
self.session.http-n keresztul latod a http sajat session-jet, amibe ha a gyerek proxyban irsz latszani fog a HTTP-ben.
Esetleges versenyhelyzetekre azert nem art felkeszulni (a gyerek masik szalban fut, mint a szulo)
"
... Now as I think of it, there's another possibility, which is somewhat simpler. The HTTP proxy is capable of reading the entire POST data before connecting to the server at all and storing it in a blob (more about blobs later). In this case the entire request together with the POST payload is fetched into memory, and after filtering it is sent to the server.
This code path is activated if you set "self.rerequest_attempts" to something greater than zero. So if you set rerequest_attempts, your stacked proxy will start earlier than the server side connection is established. ...
"
Probalgattam ezt a sefl.rerequest_attempts=1-re allitani, de nem sok sikert ertem el vele. Ilyenkor mar bele sem fut a feldolgozas az altalam beallitott response_stack proxy-ba.
gondolom a sefl itt eliras, es self-et akartal irni.
a rerequest-nel a request_stack oldalon dolgozhatod fel a POST adatokat (hiszen azok a POST request payload-jaban erkeznek)
Zorp version: Zorp 3.3.4 Revision: ssh+git://sasa@git.balabit//var/scm/git/zorp/zorp-core--mainline--3.3#master#881e162e4536a0ca69645482a9c4176b833238c7 Compile-Date: Jun 4 2009 14:17:43 Config-Date: 2009/06/04 Trace: off Debug: off IPOptions: off IPFilter-Tproxy: off Netfilter-Tproxy: on Linux22-Tproxy: off
libzorpll 3.3.0.9 Revision: devel@balabit.hu--zorp-1/zorp-lib--mainline--3.3--patch-70 Compile-Date: May 27 2009 10:43:44 Trace: off MemTrace: off Caps: on Debug: off StackDump: off
libzmisc 3.3.0.4 Revision: ssh+git://sasa@git.balabit//var/scm/git/zorp/libzmisc--mainline--3.3#master#5198413a1eb47ea3a292322c27a63b1a4d6dd3c8 Compile-Date: May 27 2009 10:45:14 Trace: on Debug: on
On Thu, 2009-06-25 at 17:31 +0200, Viktor Tuska wrote:
Szia,
koszi szepen mindjart kiprobalom ezt a self.session.http-t
Valoban elirtam, nemcsak a self-et, de a request_stack-et is. Valojaban request_stack-el tesztelgettem a rerequest_attempts=1-el, de igy a POST-nal nem latom, hogy belefutna a kod a request_stack proxy-ba.
self.request_stack["POST"] = (HTTP_STK_DATA, MagicSaverRequest)
Ha nem definialom a rerequest_attempts-t, akkor meg belefut. Elkepzelheto, hogy user error van nalam.
Az megoldhato elmeletileg, hogy a POST keres feldolgozasa utan a request_stack-ben modositom a request_url-t (redirect)?
Hmm.. a -v9 -es logban kellene latnod egy requestStack() nevu fuggvenyhivast a proxy reteg fele az megvan meg? elvben ez a fuggveny okozza a stackelest a C oldalon: static gboolean http_transfer_stack_proxy(ZTransfer2 *s, ZStackedProxy **stacked) es ez a legfontosabb feltetel: if (self->suppress_data || (self->transfer_type != HTTP_TRANSFER_NORMAL && self->transfer_type != HTTP_TRANSFER_TO_BLOB)) { *stacked = NULL; return TRUE; } a feltetelben szereplo elemek: * suppress_data: HEAD eseten TRUE, a tobbi esetben FALSE * transfer_type: rerequest_attempts eseten HTTP_TRANSFER_TO_BLOB-nak kellene lennie magyarul ugyanugy kellene stackelest probalnia a proxynak. -- Bazsi
Balazs Scheidler wrote:
Hmm.. a -v9 -es logban kellene latnod egy requestStack() nevu fuggvenyhivast a proxy reteg fele az megvan meg?
magyarul ugyanugy kellene stackelest probalnia a proxynak
Szia, nagyon szepen koszonom, tenyleg meglett a logban. Kicsit belekavarodtam mar itt a kodomba es osszedobtam egy par soros config-ot, amivel teszteltem es ebben jol mukodik. Bocs a "user error" miatt. A temahoz kapcsolodoan, a request_stack-ben modosithatom a self.session.http.request_url-t redirect-alasi celzattal? Udv, Viktor
On Fri, 2009-06-26 at 12:50 +0200, Viktor Tuska wrote:
Balazs Scheidler wrote:
Hmm.. a -v9 -es logban kellene latnod egy requestStack() nevu fuggvenyhivast a proxy reteg fele az megvan meg?
magyarul ugyanugy kellene stackelest probalnia a proxynak
Szia,
nagyon szepen koszonom, tenyleg meglett a logban. Kicsit belekavarodtam mar itt a kodomba es osszedobtam egy par soros config-ot, amivel teszteltem es ebben jol mukodik. Bocs a "user error" miatt.
A temahoz kapcsolodoan, a request_stack-ben modosithatom a self.session.http.request_url-t redirect-alasi celzattal?
Ha a szerver IP/host nevet nem modositod, akkor igen. Ha azokat is modositani akarod, akkor mar csak olyankor, ha meg a szerver oldali kapcsolat nincs meg (azaz az elso kereskor). -- Bazsi
Balazs Scheidler wrote:
A temahoz kapcsolodoan, a request_stack-ben modosithatom a self.session.http.request_url-t redirect-alasi celzattal?
Ha a szerver IP/host nevet nem modositod, akkor igen. Ha azokat is modositani akarod, akkor mar csak olyankor, ha meg a szerver oldali kapcsolat nincs meg (azaz az elso kereskor).
Koszonom az ertekes infokat. Udv, Viktor
participants (2)
-
Balazs Scheidler
-
Viktor Tuska