Andrzej Lawa wrote:

> Massai pisze:
>
> >> Najpierw pytanie techniczne: co rozumiesz przez "zaszyfrowanie
> kodu" i >> jak zamierzasz je zrealizować?
> >
> > W skrócie - to jest technicznie możliwe, bez większych problemów.
>
> Zależy, co chcesz zaszyfrować...
>
> > Działa to tak że na serwerze jest zainstalowany odpowiedni soft,
> > HTML Guardian czy coś w tym guście, pliki html/php/whatever są
> > zaszyfrowane, i są "w locie" odszyfrowywane przez tenże soft gdy
> > przeglądarka "zapyta" o dany plik.
>
> Czyli przeglądarka dostaje ten "kod" odszyfrowany, bo inaczej by go
> nie wyświetliła prawidłowo.

Oczywiście, i to jest słaby punkt takiego szyfrowania sajtu w HTML.
Pewnie, można sobie blokować wyświetlanie kodu... hłe, hłe.

I tak w połowie przeglądarek blokowanie nie zadziała, a nawet jak
zadziała, to:

telnet domena.pl 80
GET /

I mamy kod.

>
> > Zazwyczaj nie szyfruje się całości, a wybrane kluczowe elementy.
>
> To się nadaje tylko do zabezpieczeni mechanizmów działających na
> serwerze i bezpośrednio niewidocznych - czyli np. mechanizmów
> dynamicznie generujących zwykły HTML.

Ano, dynamicznie lub nie dynamicznie.

Ja wiem, że są tacy co to jeszcze robią sajty w pure html, ale mimo
wszystko...

>
> [ciach]
>
> >> W sumie jedyne, co mi przychodzi do głowy, to coś faktycznie
> >> zaszyfrowane + jakiś skrypt dekodujący, działający po stronie
> >> serwera. I to rodzi pytanie, czy serwer to dźwignie.
> >
> > Dźwignie, dźwignie.
>
> Na pewno będzie bardziej obciążony - więc klient musi wiedzieć o ile %
> ma zawyżyć potrzebną wydajność serwera na przewidywane obciążenie
> przeglądaniem.

Ten procent jest tak pomijalnie mały, że lepiej zrobiona baza, czy
lepej zrobiony sajt potrafi dać uzysk 10 czy 100 razy większy.

>
> Pozostaje też pytanie, czy dany serwer obsłuży dany dekoder.

Dekoder sobie sam "instalujesz"... de facto wgrywasz na serwer, ale nie
ważne.

Chyba że chodzi ci o kompatybilnośc z systemem na serwerze. Jak nie
podziała, to zmień serwer albo soft kodujący.


>
> >> Mam tez podejrzenie, że klient może nie mieć chęci na stronę, w
> której >> nawet prostych poprawek (np. zmiana numerów telefonów) nie
> wprowadzi, >> jak autor gdzieś zniknie - konkurencja jest spora i
> mogą zwyczajnie >> zacytować Kaczyńskiego ;)
> >
> > My szyfrujemy kluczowe elementy silnika systemu, a nie treści.
>
> To może mieć sens. Aczkolwiek ten HTML Guardian sugeruje
> zabezpieczanie także treści ;-> I to w sposób wyjątkowo idiotyczny,
> po polegający na sztucznych blokadach w samej przeglądarce, czyli
> sprawa dotyczy zasadniczo tylko mikrosyfowego eksplodera.
>
> Ale szyfrowanie samych wesnętrznych mechanizmów, które same z siebie
> nie są widoczne na zewnątrz ma sens i IMHO nie wymaga to żadnych
> dodatkowych zapisów umownych - jak dla mnie sytuacja jest analogiczna
> do dostarczenia skompilowanego programu.

My to zaczęliśmy robić dla dobra klientów, i to nie puste słowa.

Mieliśmy dosyć awantur "panie coś nie działa", po tym jak lokalny
informatyk coś sobie postanowił uślicznić. Fakt, ładnie się na tym
zarabiało, ale smród zostawał.
Szyfrujemy takie elementy do których nikt niepowołany nie powinien i
nie potrzebuje mieć dostępu.

--
Pozdro
Massai