Pomoc - Szukaj - Użytkownicy - Kalendarz
Pełna wersja: [Szukam] Użytkownik po zalogowaniu(Ograniczone edytowanie)
Forum PHP.pl > Forum > Gotowe rozwiązania > Szukam
cfneon
Witam. Szukam skryptu(lecz chyba takiego nie ma(ale co tam)).

Szukam czegoś takiego.
Mam zrobione konta użytkowników np. 10. I każde konto ma tam swój login i hasło.
I chodzi mi o to ,że np. ja rozsyłam pasy kont do ludzi. I np. wyśle takie pasy do pana X on wejdzie na strone i sie zaloguje na swojego użytkownika np. (zbychu1).
Po zalogowaniu będzie mógł tylko zedytować artykuł nr.1. i nic więcej.
Później będę chciał wysłać pasy do drugiego konta panu y. I też wyśle ,on się zaloguje tylko że on natomiast będzie mógł ze edytować tylko artykuł nr.2. i nic więcej.
Podsumowując chodzi mi o to żeby każdy użytkownik miał do swojego konta przypisany jakiś obszar który tylko on dowolnie może ze edytować.
Jeżeli ktoś kuma o co mi wgl. chodzi to prosiłbym o pomoc. Jeśli nie ma takiego skryptu to może jakieś tutki czy coś do stworzenia czegoś podobnego. Z górki thx.

Sry za nazwe tematu ale nie wiedziałem jak to nazwać.
bartoland
Jestem na etapie projektowania własnego frameworka i ostatnio mierzyłem się z tym problemem.

Generalnie sposób rozwiązania głównie zależy od architektury twojej strony i menu.
Ja rozwiązałem ten problem pisząc własny kod i jest on dokładnie dostosowany do mojego sposobu reprezentacji menu w strukturze bazy. W mojej bazie struktura menu reprezentowana jest w ten sposób, że każdy rekord menu ma jedną komórkę w której zapisuje id ojca. (Dodam, że zaprojektowałem możliwość tworzenia kilku poziomowego menu).

Rozwiązanie:
Początkowo rozwiązałem to w taki sposób: że każdy juzer miał w bazie przypisaną wartość id elementu od którego w strukturze menu w głąb miał prawo dokonać edycji.
Funkcja sprawdzająca uprawnienia działała następująco:
1. Sprawdzała czy przypadkiem nie masz uprawnień 0 - administrator - jeśli tak to zwracała true jeśli nie.
2. Sprawdzała czy zapisane id_menu od którego masz prawa edycji to nie jest przypadkiem te testowane menu jeśli było zwracała true, jeśli nie działa dalej przeszukując strukturę menu do góry czy któreś menu nie ma id zapisanego jako id_menu- uprawnień. Jeśli trafiało na to id to zwracała true a jeśli dotarła na samą górę menu i nie znalazła szukanego id zwracała false - brak prawa do edycji.

To było w pierwszej fazie dlatego pisałem w czasie przeszłym, bo szybko się okazało że dobrze by było żeby jednemu użytkownikowi można było przypisać prawa do kilku grup artykułów znajdujących się w kilku osobnych gałęziach drzewa menu.

Ja to rozwiązałem następująco:
Stworzyłem całkiem dodatkową tabelę w bazie przechowującą id użytkownika oraz id elementu menu od którego użytkownik ma prawo do edycji.
Funkcja sprawdzająca działała dokładnie tak samo jak opisana powyżej z tą różnicą że dla wszystkich elementów id_menu- pamiętajacych uprawnienia i mających id użytkownika z testowanym użytkownikiem.

Można by to rozwiązać jeszcze inaczej pamiętając w identycznej tabeli jak powyżej id użytkownika i wszystkie artykuły do których ma dostęp dany użytkownik. To jednak rozwiązanie może nawet szybciej sprawdzało by uprawnienia, ale wymagało by dodatkowego kodu przy tworzeniu artykułów do których kilka osób miało by dostęp. Należało by wszystkim tym użytkownikom dopisać w tej tabeli prawa do edycji dodawanego artykułu, oczywiście najpierw sprawdzić jacy to mieli by być użytkownicy. Dlatego zdecydowałem się jednak z tego rozwiązania zrezygnować.

Mam nadzieję, że pomogłem choć trochę,
Natomiast zastanawia mnie czy może da się to łatwiej rozwiązać. Zajmuję się programowaniem php od 2miesiecy i jeszcze dużo nie wiem. Jakby ktoś miał lepsze rozwiązanie z chęcią dowiem się jakie.
cfneon
ehhe Dziękuję ale to dla mnie Czarna magia nic z tego nie kapuje haha.gif hehe
Chyba zapomniałem napisać że dopiero zaczynam z php...
Ale jak poczytałem to bardziej byłbym zainteresowany tym drugim sposobem.tongue.gif
Jak to zrobić jak ktoś z php dopiero zaczyna i jest zielonkiem?
bartoland
Najważniejsze to się nie łam ja zacząłem dwa miesiące temu i z racji tego, że pracuje w innej dziedzinie mogę przy php siedzieć tylko nocami. Po dwóch miesiącach trochę umiem, ale przyznaje, że szybko się tego uczę i miałem styczność z programowaniem w innym języku.

Jak wspomniałem do eksperta mi jeszcze daleko, ale nie sądzę by udało ci się znaleźć taką wtyczkę która to obsłużyła w dowolnej architekturze. Chyba, że korzystasz już z jakiegoś frmeworka i po prostu będzie miał taką opcję.
darko
Generalnie to, czego szukacie/szukaliście to kontrola uprawnień, np. mechanizm ACL (access control list) już dawno wynalezione i wdrożone np. w Zend Framework. Mechanizm ten polega na definiowaniu zasobów, ról oraz zabranianiu dostępu lub jego przyznawaniu tj. ról do określonych zasobów. Polecam poszukiwania po haśle np. Zend_Acl - można spokojnie zastosować do własnych rozwiązań frameworkowych (mechanizm jest sprawdzony i w sumie się przyjął). Pozdrawiam
bartoland
Dzięki "darko" za odpowiedź.

Poczytałem troszkę na ten temat i muszę przyznać naprawdę ciekawe podejście i musi działać.
Pytanie tylko czy szybciej nauczę się je obsługiwać czy napisze swój własny. Żart - wybaczcie - szybciej bym się nauczył obsługiwać. A tak na marginesie to w takich momentach zawsze przychodzi pytanie czy używać klas już przez kogoś stworzonych czy pisać swoje. Z jednej strony po co pisać frameworka skoro już go ktoś napisał, a z drugiej przecież nie będę pisał w asemlerze. Wracając do tematu - dzięki za ostatniego posta, bo z racji małego doświadczenia nie miałem pojęcia o istnieniu takich gotowców.
Jeśli to możliwe proszę napisz czy sposób rozwiązania jaki wybrałem jest w jakiś sposób gorszy od użycia tego gotowca ( z wyjątkiem tego, że trzeba troszkę kodu wklepać ). Czy może wręcz nawet lepiej, że z racji tego, że jest docelowo pisany do konkretnej architektury może działać bardziej optymalnie (biorąc pod uwagę poprawny kod pisany z głową)questionmark.gif
darko
Cytat(bartoland @ 16.04.2010, 02:23:33 ) *
A tak na marginesie to w takich momentach zawsze przychodzi pytanie czy używać klas już przez kogoś stworzonych czy pisać swoje. Z jednej strony po co pisać frameworka skoro już go ktoś napisał, a z drugiej przecież nie będę pisał w asemlerze.

Jeśli te stworzone klasy są dobrze napisane, sprawdzone i wydajne, to nie ma sensu wynajdywać na nowo koła. Co do pisania własnego frameworka, wręcz uważam, że powinieneś poznać architekturę większości popularnych frameworków i podpatrywać najlepsze rozwiązania być może konkurencji smile.gif Może w końcu powstanie jakiś porządny framework łączący w sobie wszystko, co najlepsze z innych frameworków. Poza tym pytasz po co pisać? Jedynie w celach edukacyjnych.

Cytat(bartoland @ 16.04.2010, 02:23:33 ) *
Jeśli to możliwe proszę napisz czy sposób rozwiązania jaki wybrałem jest w jakiś sposób gorszy od użycia tego gotowca ( z wyjątkiem tego, że trzeba troszkę kodu wklepać ). Czy może wręcz nawet lepiej, że z racji tego, że jest docelowo pisany do konkretnej architektury może działać bardziej optymalnie (biorąc pod uwagę poprawny kod pisany z głową)questionmark.gif

Byłoby to możliwe, gdybym miał chwilę wolnego czasu i dostęp do Twojego kodu. Generalnie - z tego, co napisałeś - wynika, że nie znalazłeś jeszcze optymalnego rozwiązania. Poza tym piszesz o funkcjach, czyżbyś nie używał klas? Myślę, że komponent Zend_Acl można śmiało dostosować do nowych projektów. Jest to dobrze zaprojektowana klasa współpracująca z kilkoma mniejszymi klasami (np. Zand_Acl_Role, Zend_Acl_Resource). Logika zarządzania dostępem określonych ról do zasobów nie przysparza większych problemów. Dodam też, że role są dziedziczone, także można dowolnie układać hierarchię ról (przestrzegając reguł dziedziczenia uprawnień). Osobiście korzystam w większych projektach z Zend_Acl w dwóch wariantach - "listy dostępu" przechowuję w bazie danych lub pliku, dodatkowo wszystko jest powiązane z Zend_Navigation (menu generowane jest dynamicznie na podstawie danych z pliku xml). Są też inne mechanizmy, np. filtry (Java + Tomcat).
bartoland
Dzięki za sporą odpowiedź.

Co do pisania frameworka to zdecydowanie robię to w celach edukacyjnych. Raczej nigdy nie powstanie z tego komercyjny projekt smile.gif. Co do funkcji i klas to: korzystam z klas a nazewnictwo mam jeszcze nie do końca wprawione. Przeraża mnie trochę fakt ile jeszcze muszę poświęcić czasu by sprawnie tworzyć rzeczy o których piszemy. Z początku cieszyłem się, że poznałem php na tyle by móc nim się sprawnie posługiwać. I wszystko było by fajnie gdyby nie to, że za co się nie wezmę to się okazuje że jest już rozwiązanie i jedyne co trzeba to nauczyć się obsługi danej biblioteki. I znowu nic nie piszesz tylko walczysz z kolejną biblioteką smile.gif. Ok już nie piszę tekstów nie przydatnych nikomu.

Jeszcze raz dzięki. Myślę, że zrobię tak, że dokończę tego frameworka zupełnie ręcznie (fakt fektem, że co jakiś czas muszę się cofnąć i zmieniać niemal całe podejście bo nagle przychodzi do głowy, że można by to lepiej zrobić ), a potem zobaczę co można by poprawić i wtedy będę porównywał takie gotowce o których piszesz. smile.gif.

Co do kodu to szkoda czasu na analizy - tu jestem przekonany, że to co napisałem działa przynajmniej podobnie do wspomnianego przez Ciebie rozwiązania, tylko że nie ma tu mowy o żadnej uniwersalności. smile.gif.

Dzięki i pozdrawiam.

No cóż - po kilku godzinach spędzonych nad tworzeniem własnego systemu kontroli dostępu muszę stwierdzić jedno.
Zend_Acl zdecydowanie to jest to co trzeba by użyć w przypadku rozbudowanych systemów z kontrolą dostępu. Co bym nie kombinował ze swoim projektem to w końcu przy rozbudowanym serwisie wychodzi podejście podobne do zend_Acl . Dla prostej kontroli można się pobawić z własną małą klasą, ale duże projekty z kilkoma grupami użytkowników i to jeszcze z możliwością pracy na wspólnych zasobach. Szkoda czasu na pisanie samemu tym bardziej, że pewnie by mi się nie udało uzyskać takiej wydajności.

Przekonałem się do gotowca smile.gif. Jeszcze raz dzięki za rade.

Ps. Muszę się nauczyć korzystać z rzeczy które już zostały wynalezione smile.gif.
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.
Invision Power Board © 2001-2024 Invision Power Services, Inc.