[zorp-hu] WebDAV =?iso-8859-2?q?m=E1sc=EDmre?=

=?iso-8859-2?q?Czak=F3=20Kriszti=E1n?= slapic@linux.co.hu
Tue, 12 Nov 2002 12:19:27 +0100


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Idézet Balazs Scheidler 2002. november 12. 09:35 keltezésű leveléből:
> > Nagyjából összejött, amit az lmekonfon beszéltünk, azaz:
> > - - 1 IP-n sok virtualhost (standard apache namevirtualhost-ok)
> > - - https
> > - - WebDAv úgy, hogy a DAV kéréseket más címre küldjük, mint a normál
> > https kéréseket
> >
> > Eygetlen mellékhatása van (kérdezze meg kezelőorvosát, gyógyszerészét:),
> > hogy WebDAV kérés után a következő bárhonnan jövő kérést is a webdavos
> > szervernek küld. De csak az elsőt, azaz ha az ilyenkor jövő
> > authentikációs kérésre mégsemet mondok, bejön a kért lap.
> >
> > A megoldás annyira pofonegyszerű, hogy az már fáj :)
> >
> > A HttpProxy-ból származtaott osztályunkba ez kell:
> > self.session.service.dnat=""
> > self.request["OPTIONS"]  = (HTTP_REQ_POLICY, self.filterDAV)
> > self.request["PROPFIND"]  = (HTTP_REQ_POLICY, self.filterDAV)
> > self.request["PUT"]  = (HTTP_REQ_POLICY, self.filterDAV)
> > self.request["DELETE"]  = (HTTP_REQ_POLICY, self.filterDAV)
> > self.request["MKCOL"]  = (HTTP_REQ_POLICY, self.filterDAV)
> > self.request["PROPPATCH"]  = (HTTP_REQ_POLICY, self.filterDAV)
> > self.request["COPY"]  = (HTTP_REQ_POLICY, self.filterDAV)
> > self.request["MOVE"]  = (HTTP_REQ_POLICY, self.filterDAV)
> > self.request["LOCK"]  = (HTTP_REQ_POLICY, self.filterDAV)
> > self.request["UNLOCK"]  = (HTTP_REQ_POLICY, self.filterDAV)
> >
> > A PUT esetét óvatosan, hátha kell "normál" módban is.
> >
> > A filterDAV:
> > def filterDAV(self, method, url, version):
> >    self.session.service.dnat =
> > StaticNAT(SockAddrInet("davserver-címe",9443)) return HTTP_REQ_ACCEPT
>
> ezzel egyetlen problema van megpedig az, hogy ezzel folyamatosan
> valtoztatod a Service deklaraciot. Jobban jarsz, ha router=InbandRouter-t
> hasznalsz, es a self.session.server_address-t irod at (oda csak a
> sockaddrinet kell, mas nem)

Igaz. Idővel csak jó lesz. Először órákig szívtam, hogy átadjam az infót a 
megfelelő routernek, mire rájöttem, hogy a routert már nem tudom módosítani 
amikor a kliens adatot küld csak a chainert...

Az a probléma viszont még fennáll, hogy ha nem ugyanabban a sessionben a 
kliens küld egy GET kérést akkor az rosszhelyen landol. Ha van valakinek 
ötlete, hogyan lehet megfogni a DAV-os GET-et, szóljon. Mondjuk az 
authentikáció jellemző rá, de az ugye jogos a normál esetben is.
Az apache valahonnan tudja a különbséget, mert ha egy php scriptet kérek sima 
GET-el, akkor végrehajtja, ha DAV-al csinálom odaadja a forrását. Gyanítom az 
authentikációm számít, de a Zorp szintjén nem tudom dekódolni az azonosítót.

Pl. a cadaver ezeket küldi:
User-Agent: cadaver/0.18.0 neon/0.16.1
Connection: TE
TE: trailers
Host: webhome.hu:443
Authorization: Basic c2yhcLljOuPsdG6r

Digest auth esetén jobb a helyzet:
Authorization: Digest username="slapic", realm="WebDAV"
Itt a realm segíthet, feltéve ha nem jut eszébe valakinek a normál módban is 
WebDAV realmet használni, de ne jusson :)
Melyik változóban találom meg a fejléc tartalmát?
Azaz ha csinálok egy ilyet:
self.request_header["Authorization"] = (HTTP_REQ_POLICY, self.filterAUTH)
Akkor a filterAUTH mit kap meg?

És ez sem tökéletes, mert kevés kliens kezeli. Mondjuk cadaver jó, konqueror 
elszáll mint a győzelmi zászló, sitecopyt nem próbáltam.

Slapic



- -- 
Pilatus-Comp Ltd. HUNGARY * The Linux Expert * pilatuscomp@linux.co.hu
  http://www.linux.co.hu * Phone: +36-1-2481816 * Fax: +36-1-2481817
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE90OPACF6okiny5rwRAqboAJ9yUZRz12AQQkLlr5pMSsZjvdZgFwCfXQdM
EnXC1WQV/Hf7SZBYFqZewHs=
=mUZn
-----END PGP SIGNATURE-----