Aplikacja udostępniana Opcje

[MaciejW2]

Witam,
piszę aplikację w php. Kod aplikacji będzie udostępniany klientom, by mogli sobie ją zainstalować u siebie.
Nie piszcie proszę, czemu udostępniać to będę klientom w postaci kodu na ich serwerze. Tak ma być i już (IMG:style_emoticons/default/smile.gif)

Klient dostanie unikalny klucz. Do czego będzie miał prawo klient u siebie, albo na jak długo będzie miał do tego prawo, będę określał u siebie na serwerze. I teraz pytanie jak to zorganizować?
Myslałem o czymś takim, że raz na jakić czas aplikacja u klienta będzie się łączyć ze mną na serwerze i sprawdzać aktualne dane co i do kiedy. Na tej podstawie będzie albo pozwalała użytkownikowi coś zrobić albo nie. Czy idę w dobrym kierunku?
Jest może jakiś standard przechowywania takich praw co kto moze i do kiedy czy muszę coś wymyśleć własnego?

ps: tak wiem, że klient może zmienić sobie to i owo w kodzie i ominie wszelkie zabezpieczenia. Powiedzmy że to kwestia na inną dyskusję.

[!*!]

U siebie zapisujesz id, klucz, email, domenę (o ile aplikacja ma być do niej przypisana), po procesie instalacji zapisujesz gdzieś czas w cache/bazie. Logując się klient odpala skrypt który:

- sprawdza czy czas cache/baza się skończył, jeśli tak łączy się z Twoim serwerem
- na serwerze sprawdzasz po kluczu z jakiej domeny przyszło zapytanie i weryfikujesz odsyłając dane z powrotem

Jeśli z jakiegoś powodu nie można się połączyć z Twoim serwerem, zapisujesz ten fakt w bazie i ewentualnie wyskakuje komunikat o tym, ale z aplikacji nadal można korzystać. Ustaw na to jakiś limit, a po jego przekroczeniu poproś o kontakt.
Jest też kwestia mechanizmu działania po stornie serwera, jeśli do domeny nie przyszło żadne zapytanie np. w ciągu 3 miesięcy, to możesz wysłać wiadomość do klienta i wybadać czy przypadkiem nie postawił sobie tego na localhost w wewnętrznej sieci.

Jeden z prostszych sposobów, choć jednak polecałbym solidną umowę w której byłby zawarte odpowiednie klauzule o prawach klienta i o tym co się stanie po wygaśnięciu licencji.

[phpion]

Udostępniając klientowi kod umożliwiasz mu ingerencję w niego, a więc i usunięcie/zakomentowanie/modyfikację kodu sprawdzającego licencję. Chyba, że użyjesz np. ionCube i w zakodowanym pliku umieścisz sprawdzanie licencji. Również będzie można to obejść, ale już trudniej. W takim przypadku możesz zrezygnować z odpytywania Twojego serwera, ale równocześnie nie możesz ze swojej bazy sterować licencjami. Wszystko ma swoje plusy i minusy.

[MaciejW2]

Jeden z prostszych sposobów, choć jednak polecałbym solidną umowę w której byłby zawarte odpowiednie klauzule o prawach klienta i o tym co się stanie po wygaśnięciu licencji.

Tak, oczywiscie, to będzie, nie mniej jednak chciałbym mieć taki mini sprawdzonko.
Twoja propozycja wydaje się całkiem sensowna. Dane będą szły cURLem, wiec raczej domeny nie sprawdze, co najwyżej IP.
Sprobuje to wdrozyc, zobacze co wyjdzie (IMG:style_emoticons/default/smile.gif)

Ewentualne inne pomysły rownież mile widziane (IMG:style_emoticons/default/smile.gif)

edit:
@phpion tak, wiem.... zdaje sobie z tego sprawe. Też zastanawiałem się nad ionCube, ale wowczas po stronie klienta musi być czytnik do tego, nieprawdaż?
No i sterowanie licencją chciałbym mieć po stronie serwera, by móc wydłuzac lub innego typu rzeczy.

[phpion]

Z tego co się orientuję to ionCube jest dostępny na większości serwerów, nie powinno być z tym problemu. Możesz nadal odwoływać się do swojego serwera w zakodowanym kodzie. Jednak ionCube wiąże się z wydatkiem. Żeby nie pisać jawnego kodu możesz ewentualnie skorzystać z base64 + eval do wykonania kodu. Tak czy inaczej mając dostęp do plików można to sobie odkodować i zmienić lub wręcz usunąć.

[!*!]

Twoja propozycja wydaje się całkiem sensowna. Dane będą szły cURLem, wiec raczej domeny nie sprawdze, co najwyżej IP.

A jaki problem wysłać domenę curlem jako parametr?

Też zastanawiałem się nad ionCube, ale wowczas po stronie klienta musi być czytnik do tego, nieprawdaż?
No i sterowanie licencją chciałbym mieć po stronie serwera, by móc wydłuzac lub innego typu rzeczy.

ionCube jest na każdym dobrym serwerze. Inną kwestią jest to, że jest słaby i od dawna istnieją programy umożliwiające jego "odkodowanie".

[MaciejW2]

klienci nie bedą raczej korzystac z hostingow, tylko będą mieli własne serwery

A jaki problem wysłać domenę curlem jako parametr?

No ale to wtedy beda musial gdzies w kodzie/parametrach miec zapisaną tę domenę. Jesli tak, to jaki sens wysylacz jeszcze domene, skoro i tak będę wysyłał unikalny klucz dla tego klienta?

[!*!]

No ale to wtedy beda musial gdzies w kodzie/parametrach miec zapisaną tę domenę. Jesli tak, to jaki sens wysylacz jeszcze domene, skoro i tak będę wysyłał unikalny klucz dla tego klienta?

A jak ktoś skopiuje skrypt i będzie korzystał na tym samym kluczu? Patrz Windows OEM (IMG:style_emoticons/default/wink.gif)
Poza tym po co chcesz coś zapisywać, jak wystarczy ją tylko pobrać i wysłać.

Zresztą... takie manewry są dobre, tylko dla firm które nie mają na pokładzie programistów. Pierwszy lepszy żółtodziób prędzej czy później wpadnie na to jak to wszytko obejść.

[MaciejW2]

A jak ktoś skopiuje skrypt i będzie korzystał na tym samym kluczu? Patrz Windows OEM wink.gif
Poza tym po co chcesz coś zapisywać, jak wystarczy ją tylko pobrać i wysłać.

No ale jak ja pobiore domene na jakiej pracuje serwer?

Zresztą... takie manewry są dobre, tylko dla firm które nie mają na pokładzie programistów. Pierwszy lepszy żółtodziób prędzej czy później wpadnie na to jak to wszytko obejść.

Glownym celem jest sterowanie licencją dla danego klienta. Klient dotaje aplikacje np. za free do testow na 3 miesiace. Po tym okresie albo wykupi albo przestanie korzystac albo np. zaplaci tylko za kolejne 3 miesiace. Dzieki temu, bez ingerencji w jego kod, bede mogl z mojej bazy sterowac tym do czego ma dostep.

Jesli jakis ich programista zlamie to zabezpieczenie, to lamie warunki licencji na wlasne ryzyko. Tego juz nie przeskocze

[!*!]

No ale jak ja pobiore domene na jakiej pracuje serwer?

A jak się pobiera domenę w skryptach PHP?

Glownym celem jest sterowanie licencją dla danego klienta. Klient dotaje aplikacje np. za free do testow na 3 miesiace. Po tym okresie albo wykupi albo przestanie korzystac albo np. zaplaci tylko za kolejne 3 miesiace. Dzieki temu, bez ingerencji w jego kod, bede mogl z mojej bazy sterowac tym do czego ma dostep.

Jesli jakis ich programista zlamie to zabezpieczenie, to lamie warunki licencji na wlasne ryzyko. Tego juz nie przeskocze

Tylko co byś chciał zrobić po tym okresie testowym? Wyłączyć skrypt? W zasadzie nie możesz, to podlega pod jakiś paragraf o ingerencji w nie Twoją własność (serwer i dane wprowadzone przez klienta).

[MaciejW2]

No dobra, co do domeny masz racje (IMG:style_emoticons/default/smile.gif)

Co chce zrobic? Np. odblokowac skrypt by klient mogl korzystac z calej funkcjonalnosc. Albo zablokowac skrypt do jakiejs funkcjonalnosci.
No ale ja nie bede ingerowal w serwer klienta. Bede tylko mowil mojej aplikacji, ktora jest zainstalowana u klietna, co moze robic a co nie w tejze aplikacji. To sie lapie pod ten paragraf co mowisz?

[!*!]

Przejrzyj lub napisz nowy wątek na http://forumprawne.org/ wyjaśnią Ci to lepiej. Blokada do określonych czynności np. tylko do odczytu brzmi już lepiej, ale... na upartego można kogoś podciągnąć do odpowiedzialności tylko dlatego że zalogował się na FTP, znając login i hasło podane przez klienta. Po prostu zabezpiecz się umową skonsultowaną z prawnikiem, ewentualnie wspomnij coś o BSA czy podobnych tworach.

[MaciejW2]

ale... na upartego można kogoś podciągnąć do odpowiedzialności tylko dlatego że zalogował się na FTP, znając login i hasło podane przez klienta.

Ale ja nie zamierzam sie logowac do ftp klienta. Jak juz pisalem, po to mi jest potrzebny ten mechanizm, zebym ja juz nic w kodzie na serwerze u klienta nie musial robic.

[!*!]

Ale ja nie zamierzam sie logowac do ftp klienta. Jak juz pisalem, po to mi jest potrzebny ten mechanizm, zebym ja juz nic w kodzie na serwerze u klienta nie musial robic.

I właśnie dlatego nie jest to takie proste. Blokując aplikację, zmieniasz ją, tym samym wprowadzasz zmiany np. w pliku konfiguracyjnym. Jeśli zrobisz opcje tylko do odczytu, to co z edycją? Też zablokujesz? A jeśli tak, to uniemożliwisz poprawę błędów do czegoś co zostało wprowadzone w okresie trwania licencji, tym samym złamiesz swój własny regulamin.

[MaciejW2]

No ale jak to? Koles dostaje licencje na 3 miesiace. Jasno jest to zaznaczone, ze po tym czasie jak nie oplaci to wygasa mu funkcjonalnosc w takiej a takiej formie. Przeciez tak dziala chyba wiekszosc licencji.

[!*!]

Logicznie rzecz biorąc tak, masz racje, ale to co wprowadził klient należy tylko i wyłącznie do niego, dlatego trudno jest zablokować aplikację tym bardziej, że chcesz to zrobić zdalnie. A zdalne połączenie można podciągnąć pod nieautoryzowany dostęp, a to naraża klienta na straty itd.

Skontaktuj się z prawnikiem, obwaruj się klauzulą w umowie innego, prostego wyjścia nie ma.

[MaciejW2]

ok (IMG:style_emoticons/default/smile.gif)