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

do góry

Użytkownik "Andrzej Lawa" <a...@l...SPAM_PRECZ.com> napisał

> Najpierw pytanie techniczne: co rozumiesz przez "zaszyfrowanie kodu" i
> jak zamierzasz je zrealizować?
>
> Bo generalnie kod w HTML jest interpretowany przez przeglądarkę - a jak
> jest czytelne dla przeglądarki, to i człowiek sobie ją obejrzy. Albo
> strona w ogóle nie będzie działać ;->


kilka linijek kodu w js, przeglądarka w locie to odkodowuje.

Pozdrawiam
tp

do góry

> Mam pytanie otóż chcę wykonać stronę WWW dla kogoś i nie chcę aby ktoś
> wykorzystał potem moje rozwiązania i pomysły dlatego chce dokonać
> zaszyfrowania kodu i w takiej postaci przekazać stronę.

1. technicznie rzecz biorac jak masz napisane cos w jezyku interpretowalnym
to jakiekolwiek zaszyfrowanie jest bez sensu gdyz interpreter musi miec do
tego dostep. Jak ma dostep to i ktos kto ma dostep do serwera/interpretera
da rade tez miec do kodu dostep.

2. "zaszyfrowac" sie skutecznie nie da. Mozna utrudnic wykorzystanie kodu
przez roznego rodzaju mechanizmy "zaciemniajace" kod. Jak ktos bedzie uparty
to sobie poradzi. Tylko jak bedzie umial to tez sobie lepiej napisze.

3. Na miejscu klienta zastanowilbym sie nad wspolpraca z tworca ktory chce
sprzedac dzielo (skasowac za to kase) ale bez praw do tego dziela (bo
wszelkie zmiany to tez u niego). WIadomym jest, ze strona bedzie ewoluowac i
ktos te zmiany musi dokonywac. Nie zdecydowalbym sie na wspolprace z kims
kogo nie bedzie mozna wymienic.

4. Mam takie wrazenie, ze tylko osoby o niklych umiejetnosciach uwazaja
swoje rozwiazania za tak genialne aby nikomu ich nie pokazac. A moze to
strach przed ocena specjalistow, ktorzy dostrzegliby fuszerke ? A moze
chcesz ukryc, ze Twoje "autorskie" rozwiazanie to w 75% kopia innego ?

IMO takie "szyfrowanie" jest bez sensu. Lepiej jasno powiedziec
zleceniodawcy (dac wybor): kupujesz strone z prawem do modyfikacji czy
kupujesz strone tak jak jest bez tego prawa. I klient decyduje. Bo jak
zamierzasz wsadzic na mine nieobeznanego w temacie to nieetyczne


Icek

do góry

Massai pisze:

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

I chwałą im za to. Jak widzę te przebajerowane, wypełnione zgiełkiem
strony, które są ciężkie do nawigacji i sprawiają problemy w sprzęcie
mniej typowym (np. kieszonkowym), to mnie szlag trafia.

[ciach]

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

Zgoda, ale powinien o tym wiedzieć.

>> Pozostaje też pytanie, czy dany serwer obsłuży dany dekoder.
>
> Dekoder sobie sam "instalujesz"... de facto wgrywasz na serwer, ale nie
> ważne.

Jeśli jest to TWÓJ prywatny serwer - jasne.

Jeśli jest to serwer klienta postawiony na jednym systemie i dość
prosty, a ty chcesz mu wmusić swój ulubiony dekoder z zupełnie innego
systemu i wymagający bardziej zaawansowanego oprogramowania serwerowego,
to klient się zjeży.

A jeśli serwer jest wynajmowany gdzieś w świecie, to klient może nawet
nie wiedzieć, co tam chodzi.

> Chyba że chodzi ci o kompatybilnośc z systemem na serwerze. Jak nie

Też.

> podziała, to zmień serwer albo soft kodujący.

Tylko ty, jako autor ze szczególnymi wymaganiami, musisz za to zapłacić,
bo klient nie będzie chciał płacić za fanaberie autora ;->

[ciach]

>> 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ł.

Jeśli jest to zrobione porządnie i bezwzględnie zgodne z ogólnymi
standardami tak, że będzie działać prawidłowo z każdą przeglądarką, to
fajnie.

(na punkcie standardów mam od niedawna duży "uraz" po tym, jak przejąłem
system informatyczny z magazynem obsługiwanym przez Javę tak skopaną, że
działało wyłącznie na IE6 - jak ktoś sobue uaktualnił do nowszej
przelgądarki... albo dostał vistę z nowym komputerem...)

> Szyfrujemy takie elementy do których nikt niepowołany nie powinien i
> nie potrzebuje mieć dostępu.

I bardzo dobrze.

do góry

tp pisze:

>> Bo generalnie kod w HTML jest interpretowany przez przeglądarkę - a jak
>> jest czytelne dla przeglądarki, to i człowiek sobie ją obejrzy. Albo
>> strona w ogóle nie będzie działać ;->
>
>
> kilka linijek kodu w js, przeglądarka w locie to odkodowuje.

Skrypt? To i mam dekoder w ręku ;)

do góry

Andrzej Lawa napisał(a):
> Najpierw pytanie techniczne: co rozumiesz przez "zaszyfrowanie kodu" i
> jak zamierzasz je zrealizować?
Zerknij na http://phpencoder.pl

> Bo generalnie kod w HTML jest interpretowany przez przeglądarkę - a jak
> jest czytelne dla przeglądarki, to i człowiek sobie ją obejrzy. Albo
> strona w ogóle nie będzie działać ;->
Nie do konca tak jest. Strona moze byc napisana w np php a skrypty php
generuja wynik czyli to co widzisz w przegladarce. Po drodze jeszcze
lacza sie z baza danych, wykonuja jakies operacje itp itd

> zaszyfrowane + jakiś skrypt dekodujący, działający po stronie serwera. I
> to rodzi pytanie, czy serwer to dźwignie.
Tak. Link powyzej

Poza tym wystarczu zakodowac jedynie 1 (slownie jeden) plik php
zawierajacy kluczowe rozwiazania (tzn funkcje, klasy, obiekty czy jak
tam to napiszesz.)


--
Pozdrawiam
Er
mailto:er2002@##WYKASUJ##poczta.onet.pl

do góry

ER pisze:

>> Bo generalnie kod w HTML jest interpretowany przez przeglądarkę - a jak
>> jest czytelne dla przeglądarki, to i człowiek sobie ją obejrzy. Albo
>> strona w ogóle nie będzie działać ;->
> Nie do konca tak jest.

Jest, jest.

> Strona moze byc napisana w np php a skrypty php
> generuja wynik czyli to co widzisz w przegladarce. Po drodze jeszcze
> lacza sie z baza danych, wykonuja jakies operacje itp itd

No i właśnie o to się pytałem: CO konkretnie będzie kodowane. Czyli
szyfrujesz de facto nie stronę lecz program ją na bieżąco tworzący.

Bo niektórzy producenci "systemów szyfrujących" bredzą o zabezpieczaniu
przed zapisaniem nawet obrazków na stronach ;)

do góry

Andrzej Lawa wrote:

> Massai pisze:
>
> > Ja wiem, że są tacy co to jeszcze robią sajty w pure html, ale mimo
> > wszystko...
>
> I chwałą im za to. Jak widzę te przebajerowane, wypełnione zgiełkiem
> strony, które są ciężkie do nawigacji i sprawiają problemy w sprzęcie
> mniej typowym (np. kieszonkowym), to mnie szlag trafia.

No, po części się z Tobą zgadzam, ale też zrobienie czegoś minimalnie
bardziej skomplikowanego niż "nazywamy się tak i tak, tel...", jak
choćby mapka z opcją wyświetlenia reselerów z danego regionu, wymaga
mnożenia bytów ponad potrzebę.

Faktem jest też że często zasyfione strony w asp są robione tak tylko
dlatego że to "rozwiązanie dostarczone przez wiodącą firmę na rynku".

Ładnym przykładem była gazeta.pl, to co się jeszcze parę miesięcy temu
działo, to był dramat. Nawet na całkiem mocnym sprzęcie przeglądarka
potrafiła zamrozić kompa na kilkanaście sekund, a przewijanie odbywało
się jakby przeglądarka się jąkała... na ich szczęście jakiś czas temu
zoptymalizowali soft.

>
> > podziała, to zmień serwer albo soft kodujący.
>
> Tylko ty, jako autor ze szczególnymi wymaganiami, musisz za to
> zapłacić, bo klient nie będzie chciał płacić za fanaberie autora ;->

To chyba jasne... Jest umowa, albo kupuje się serwer, dedyka czy
wirtualny dla klienta, w określonej cenie, albo jest dołączona
specyfikacja co ma serwer mieć. przed podpisaniem klient się pyta
swojego admina czy to mają i się decyduje albo nie.

Swoją drogą wykorzystywanie firmowych serwerów do zastosowań webowych,
czy to proste, do stron, czy do czegoś bardziej wyuzdanego, jakieś
wsparcie sprzedaży itp - imho mija się z celem. Ale to już nie na temat.

--
Pozdro
Massai

do góry

Andrzej Lawa napisał(a):
> ER pisze:
>>> Bo generalnie kod w HTML jest interpretowany przez przeglądarkę - a jak
>>> jest czytelne dla przeglądarki, to i człowiek sobie ją obejrzy. Albo
>>> strona w ogóle nie będzie działać ;->
>> Nie do konca tak jest.
> Jest, jest.

Tyle ze widzisz jedynie wynik dzialania skryptu.
Czyli faktycznie goly kod html ale ten kod jest wygenerowany dynamicznie.
Nie wiem czy jasno to opisalem. Podam przyklad: wchodzisz na strone i
zaznaczasz:
SUV, 2.0, ABS, cos tam jeszcze... i w wyniku skrypt po polaczeniu sie z
baza danych zwroci strone w html zawierajaca pozycje spelniajace Twoje
kryteria.
I ta strona (ten html) jest jawnie widoczny ale zostal dynamicznie
wygenerowany przez skrpyty ktore ma napisac pytajacy w watku.

> No i właśnie o to się pytałem: CO konkretnie będzie kodowane. Czyli
> szyfrujesz de facto nie stronę lecz program ją na bieżąco tworzący.
Skrypt ktory dziala na serwerze i w wyniku jego dzialania gotowa strona
jest wyslana do przegladarki odwiedzajacego.
Czyli dziala on jak np Word, ktorym otwierasz jakis dokument napisany
przez kogos innego. Niby masz ten dokument (plik) ale bez worda go nie
zobaczysz (upraszczajac rzecz jasna sprawe)

--
Pozdrawiam
Er
mailto:er2002@##WYKASUJ##poczta.onet.pl

do góry

ER pisze:

>>>> Bo generalnie kod w HTML jest interpretowany przez przeglądarkę - a jak
>>>> jest czytelne dla przeglądarki, to i człowiek sobie ją obejrzy. Albo
>>>> strona w ogóle nie będzie działać ;->
>>> Nie do konca tak jest.
>> Jest, jest.
>
> Tyle ze widzisz jedynie wynik dzialania skryptu.

Nie wnikam.

> Czyli faktycznie goly kod html ale ten kod jest wygenerowany dynamicznie.
> Nie wiem czy jasno to opisalem. Podam przyklad: wchodzisz na strone i
> zaznaczasz:

[ciach]

Generalnie nie dogadujemy się względem nomenklatury ;)

Dla mnie "strona www" to kod wysyłany do przeglądarki - czyli HTML z
dodatkami, który siłą rzeczy musi być mniej lub bardziej czytelny.

Nie obchodzi mnie, jaki "silnik" tworzy te pliki na serwerze - jeśli o
mnie chodzi może to być nawet program-serwer, który sam na bieżąco
generuje stronę.

[ciach]

>> No i właśnie o to się pytałem: CO konkretnie będzie kodowane. Czyli
>> szyfrujesz de facto nie stronę lecz program ją na bieżąco tworzący.
> Skrypt ktory dziala na serwerze i w wyniku jego dzialania gotowa strona
> jest wyslana do przegladarki odwiedzajacego.
> Czyli dziala on jak np Word, ktorym otwierasz jakis dokument napisany
> przez kogos innego. Niby masz ten dokument (plik) ale bez worda go nie
> zobaczysz (upraszczajac rzecz jasna sprawe)
>

Mooooooooooooooooocno chybione porównanie. Wręcz totalnie błędne :-P

Word jest serwerem, ja jestem przeglądarką, a skryptem generującym
stronę (dokument) jest jego autor.

do góry