Zaloguj się

Jog Jajcusia

xmpp:jajcus@jajcus.net

Powrót na stronę główną

<< Pożeracz ramu MAILER-DAEMON ma nowych przyjaciół. >>

No i stało się

16 września 2004 22:25:49 | kategorie: html itp., pyxmpp,

Przed chwilą dokonałem zmian w PyXMPP w kierunku który doradził Jarek, ostatecznie zrobiłem tak:

  • fr -> from_jid
  • to -> to_jid
  • typ -> stanza_type
  • sid -> stanza_id

Dla ułatwienia życia sobie, a także innym developerom używającym PyXMPP (są tacy?) przygotowałem też skrypt poprawiający kod pythona używający starych nazw. Mnie nawet ten skrypt nic nie popsuł.

A w pracy wkurzałem się na interfejs WWW zarządzania switchy DLink i access-pointów Proxima. Chcę dać na zewnątrz (żebym miał w domu, czy gdzieś w terenie) dostęp do tych urządzeń. Że urządzenia nie mają SSL, to nie mogę tego po prostu przeroutować, więc robię to przez reverse-proxy na Apache z mod_ssl. Pierwszy problem to bezwzględne linki na stronach tych interfejsów. Ale to załatwia (teoretycznie) mod_proxy_html. Tylko, że mod_proxy_html parsuje otrzymany HTML, poprawia co trzeba i serializuje od nowa. Ale jak to ma działać na czymś co do HTMLa jest tylko miejscami podobne (tak jest w przypadku Proxima -- po prostu koszmar)? No nie całkiem działa. Do przeglądarki dochodzi już poprawny HTML, ale wyrażający nie całkiem to co autor miał na myśli. Miejscami prześwituje kod JavaScript, inne rzeczy poprzestawiane itp. Z tym pewnie będę jeszcze długo walczył.

mod_proxy_html poprawia też skrypty JavaScript w kodzie HTML, robi to na głupa, ale jak się postarać, to można uzyskać ciekawe efekty. Gorzej ze skryptami zewnętrznymi, w osobnych dokumentach. W przypadku switchy nie jest niby źle, bo w zewnętrznych skryptach nie ma zaszytych żadnych ścieżek, ale za to są serwowane jako text/html, a co za tym idzie mod_proxy_html próbuje z nich robić poprawnego HTMLa. No i taki skrypt po dodaniu <html><body> na początku i po przetworzeniu tagów w środku nie bardzo chciał działać. Musiałem więc tak skonfigurować mod_proxy_html, aby zajął się jedynie dokumentami *.html.

Proximy za to mają zaszyte ścieżki w plikach *.js, jednak serwowanych poprawnie, jako text/javascript. mod_proxy_html w ogóle tego nie rusza, za to znalazłem jeszcze mod_ext_filter (standardowa część Apache 2.x). Przy pomocy tego moduliku można serwowane dokumenty przepuścić przez zewnętrzny program. A więc przepuściłem przez seda i poprawiłem ścieżki gdzie trzeba. Nawet zadziałało. Chyba tego samego modułu wraz z sedem, albo jakimś mądrzejszym skryptem w perlu/awku/pythonie będę musiał użyć do tego paskudnego HTMLa z Proxima. To jest do zrobienia, ale może być z tym kupa roboty i nie wiem czy się wcześniej nie poddam.

Komentarze

smoku

17 września 2004 09:12:13

A nie lepiej sobie po prostu stunnel postawić?

Jajcus

17 września 2004 09:20:35

I co ten stunnel pomoże, jak w HTMLu są odwołania do wewnętrznych IP, po "http://"?

smoku

17 września 2004 09:28:46

/me dziś nie myśli.
Proszę o zignorowanie. ;-)

Jajcus

17 września 2004 09:42:08

Ja też musiałem się chwilę zastanowić, czemu właściwie stunnela nie użyłem. I już chciałem odpisać, że tylko dlatego, że o nim nie pomyślałem ;-)

D-

19 września 2004 14:54:05

Stunnel, jak stunnel, ale może jakiś VPN?

Jajcus

19 września 2004 15:34:15

VPNa brałem pod uwagę. Ale to komplikuję sprawę od strony klienta, a nie wiem skąd będę musiał tam zaglądać. No i VPN daje większy dostęp do tej sieci do zarządzania, a nie koniecznie gdy będę gdzies chciał udostępnić dostęp do interfejsu WWW to od razu chciałbym dawać pełne wejście do sieci. Poza tym proxy będzie mi logować wszystkie połączenia w jednym miejscu.

Dodaj nowy komentarz

Dostępne jest formatowanie Textile

Podpis:
Treść:
Strona WWW (opcjonalnie):
Wpisz kod:code
 
 

Śledzenie komentarzy (RSS) TrackBack URI

Jesteście obserwowani...