From jacek w erp5.pl Thu Feb 14 09:17:32 2008 From: jacek w erp5.pl (Jacek Medrzycki) Date: Thu, 14 Feb 2008 09:17:32 +0100 Subject: [Erp5-poland] =?utf-8?q?Security_zmieniaj=C4=85ce_si=C4=99_w_czas?= =?utf-8?q?ie_=C5=BCycia_systemu?= In-Reply-To: <20080213175152.1ba2ce1a@mover> References: <20080213153716.1e0cebec@mover> <47B30EC0.7080503@erp5.pl> <20080213163958.04b27ee9@mover> <47B3188E.1030804@erp5.pl> <20080213175152.1ba2ce1a@mover> Message-ID: <47B3F91C.50300@erp5.pl> Łukasz Nowak pisze: > Wybacz. Źle to ująłem > > Przez błąd rozumiałem fakt, że nie jest brana > pod uwagę poprawnie definicja poziomów dostępu - dokładnie jej > dodatkowe restrykcje. > Czekaj, bo teraz ja nie łapię. Jakie dodatkowe restrykcje nie są brane pod uwagę? > Wywoływanie interaction workflow uznaję za workaround, ale workaround > jako taki nie rozwiązuje problemu a go zakrywa - To nie jest workaround, tylko taka jest architektura systemu - wszelka zmiana uprawnień na obiekcie musi być wymuszona ręcznie przez developera. W przeciwnym wypadku - ponieważ security może być oparte na czymkolwiek (nie tylko kategoriach ale obiektach powiązanych z danym obiektem itp) - przeliczenie security musiałoby być wywoływane _przy każdej_ edycji obiektu, i to dla wszystkich obiektów w systemie (a przynajmiej dla wszystkich, do których z danego obiektu da się dojść po grafie powiązań)! Obawiam się, że wtedy nieszczęsne pierdykaty byłyby demonem szybkości w porównaniu z maszynką security. To developer ma wiedzieć, która zmiana na obiekcie może mieć wpływ na security i dla jakich ewentualnych _innych_ obiektów i odpowiednio zakutalizować je. Szczerze powiedziawszy, nie widzę tu dziury ani zagrożenia dla bezpieczeństwa. J. From lukasz.nowak w ventis.com.pl Thu Feb 14 09:42:47 2008 From: lukasz.nowak w ventis.com.pl (=?UTF-8?B?xYF1a2Fzeg==?= Nowak) Date: Thu, 14 Feb 2008 09:42:47 +0100 Subject: [Erp5-poland] =?utf-8?q?Security_zmieniaj=C4=85ce_si=C4=99_w_czas?= =?utf-8?q?ie_=C5=BCycia_systemu?= In-Reply-To: <47B3F91C.50300@erp5.pl> References: <20080213153716.1e0cebec@mover> <47B30EC0.7080503@erp5.pl> <20080213163958.04b27ee9@mover> <47B3188E.1030804@erp5.pl> <20080213175152.1ba2ce1a@mover> <47B3F91C.50300@erp5.pl> Message-ID: <20080214094247.40359bef@mover> On 2008-02-14, 09:17:32 Jacek Medrzycki wrote: > Łukasz Nowak pisze: > > Wybacz. Źle to ująłem > > > > Przez błąd rozumiałem fakt, że nie jest brana > > pod uwagę poprawnie definicja poziomów dostępu - dokładnie jej > > dodatkowe restrykcje. > > > Czekaj, bo teraz ja nie łapię. > Jakie dodatkowe restrykcje nie są brane pod uwagę? Pole Condition w manage_editRolesForm. > > Wywoływanie interaction workflow uznaję za workaround, ale > > workaround jako taki nie rozwiązuje problemu a go zakrywa - > To nie jest workaround, tylko taka jest architektura systemu - > wszelka zmiana uprawnień na obiekcie musi być wymuszona ręcznie przez > developera. W przeciwnym wypadku - ponieważ security może być oparte > na czymkolwiek (nie tylko kategoriach ale obiektach powiązanych z > danym obiektem itp) - przeliczenie security musiałoby być wywoływane > _przy każdej_ edycji obiektu, i to dla wszystkich obiektów w systemie > (a przynajmiej dla wszystkich, do których z danego obiektu da się > dojść po grafie powiązań)! Obawiam się, że wtedy nieszczęsne > pierdykaty byłyby demonem szybkości w porównaniu z maszynką security. > To developer ma wiedzieć, która zmiana na obiekcie może mieć wpływ na > security i dla jakich ewentualnych _innych_ obiektów i odpowiednio > zakutalizować je. Mam inne podejście. Skoro jest jakaś funkcjonalność, mogę przyjąć ryzykowne założenie, że działa, prawda? To nie zadziałało - ustawienie Condition nie zostało wzięte pod uwagę, przy edycji obiektu. Ja _AKCEPTUJĘ_ zastosowanie workaroundu w postaci dodania interaction workflow na portal type'ach, dla których zdefiniowałem security, które ma condition. Co do architektury systemu (nie tylko security) - na pewno jakaś istnieje - nie znam jej, dlatego zadałem pytanie, które zaczęło wątek :) Z drugiej strony nie znając wewnętrznych założeń działania security mogę mieć przez pewien czas postawę roszczeniową "no skoro coś jest, to dlaczego nie działa". Prawda? :) > Szczerze powiedziawszy, nie widzę tu dziury ani > zagrożenia dla bezpieczeństwa. Bo nie ma, piję do czegoś innego. Pozdrawiam, Łukasz -- Łukasz Nowak R&D Ventis http://www.ventis.com.pl/ tel: +48 32 768 16 85 fax: +48 32 392 10 61 ``Use the Source, Luke...'' I am only craftsman. From jacek w erp5.pl Thu Feb 14 10:19:05 2008 From: jacek w erp5.pl (Jacek Medrzycki) Date: Thu, 14 Feb 2008 10:19:05 +0100 Subject: [Erp5-poland] =?utf-8?q?Security_zmieniaj=C4=85ce_si=C4=99_w_czas?= =?utf-8?q?ie_=C5=BCycia_systemu?= In-Reply-To: <20080214094247.40359bef@mover> References: <20080213153716.1e0cebec@mover> <47B30EC0.7080503@erp5.pl> <20080213163958.04b27ee9@mover> <47B3188E.1030804@erp5.pl> <20080213175152.1ba2ce1a@mover> <47B3F91C.50300@erp5.pl> <20080214094247.40359bef@mover> Message-ID: <47B40789.9080107@erp5.pl> Łukasz Nowak pisze: > On 2008-02-14, 09:17:32 > Jacek Medrzycki wrote: > > >> Łukasz Nowak pisze: >> >>> Wybacz. Źle to ująłem >>> >>> Przez błąd rozumiałem fakt, że nie jest brana >>> pod uwagę poprawnie definicja poziomów dostępu - dokładnie jej >>> dodatkowe restrykcje. >>> >>> >> Czekaj, bo teraz ja nie łapię. >> Jakie dodatkowe restrykcje nie są brane pod uwagę? >> > > Pole Condition w manage_editRolesForm. > Napisałęs Dziwna sprawa. Użytkownik dodaje Person. Jest ok. Użytkownik robi przypisanie 'role/internal'. Nadal ma prawa do obiektu. Czyszczę wszystkie cache factory. Nadal ma Assignora. Dopiero jak w portal_types/Person kliknę 'Update role settings' znikają mu uprawnienia. No to jest IMHO działanie prawidłowe. Rolki nie przeliczają się same, trzeba to wymusić. Najlepiej właśnie przez interaction workflow (w projekcie niemieckim był w ogóle osobny workflow pt. security_interaction_workflow, który był podpinany do każdego portal_typu i jego interaction metod sprawdzało portal_type obiektu i dokonywało stosownych czarów). > Mam inne podejście. Skoro jest jakaś funkcjonalność, mogę przyjąć > ryzykowne założenie, że działa, prawda? To nie zadziałało - ustawienie > Condition nie zostało wzięte pod uwagę, przy edycji obiektu. > Czekaj. Kiedy nie zadziałało ustawienie Condition? To object.isMemberOf('role/internal') było w conditionie? No i OK. Zmiana w obiekcie na /role/internal nie spowoduje automatycznego przeliczenia security na obiekcie z powodów wyłuszczonych w poprzednim poście. I to IMHO nie ma związku z tym, czy to jest condition czy nie, po prostu rolki przeliczane są na żądanie a nie w locie. Według mnie to działa tak, że po odpaleniu updateLocalRolesOnSecurytiyGroups przelatuje po wszystkich definicjach rolek i dla każdej generuje stosowny mapping. Jeśli condition nie jest spełnione, to po prostu pomija tę definicję rolki, tak jakby jej nie było. Czyli to cały czas jest statyczne a nie dynamiczne condition (czyli jeśli w condition da się warunek, że day_of_week ma być środa, i update zrobi się w środę, to w czwartek dalej będzie się zachowywać jakby condition był spełniony, o ile się na nowo nie przeliczy). Chyba że się strasznie mylę i to działa inaczej, ale wszelkie moje doświadczenia wskazują, że działa tak jak napisalem. J. From lukasz.nowak w ventis.com.pl Thu Feb 14 10:29:08 2008 From: lukasz.nowak w ventis.com.pl (=?UTF-8?B?xYF1a2Fzeg==?= Nowak) Date: Thu, 14 Feb 2008 10:29:08 +0100 Subject: [Erp5-poland] =?utf-8?q?Security_zmieniaj=C4=85ce_si=C4=99_w_czas?= =?utf-8?q?ie_=C5=BCycia_systemu?= In-Reply-To: <47B40789.9080107@erp5.pl> References: <20080213153716.1e0cebec@mover> <47B30EC0.7080503@erp5.pl> <20080213163958.04b27ee9@mover> <47B3188E.1030804@erp5.pl> <20080213175152.1ba2ce1a@mover> <47B3F91C.50300@erp5.pl> <20080214094247.40359bef@mover> <47B40789.9080107@erp5.pl> Message-ID: <20080214102908.3680133c@mover> On 2008-02-14, 10:19:05 Jacek Medrzycki wrote: > Napisałęs > >> Dziwna sprawa. Użytkownik dodaje Person. Jest ok. Użytkownik robi >> przypisanie 'role/internal'. Nadal ma prawa do obiektu. Czyszczę >> wszystkie cache factory. Nadal ma Assignora. Dopiero jak w >> portal_types/Person kliknę 'Update role settings' znikają mu >> uprawnienia. > > No to jest IMHO działanie prawidłowe. Dobrze. Teraz też tak uważam. Wcześniej nie miałem podstaw do żadnego wniosku, przyjąłem pasuje mnie za wiążące i uznałem, że coś nie działa. Skoro coś zdefiniowałem ma działać, prawda? Nie działa jak myślę, zadaję pytanie. Okazuje się, że trzeba użyć interaction workflow. To dziwię się dlaczego. Teraz sprawa jest dla mnie jasna - używaj interaction workflow, no questions :) > Rolki nie przeliczają się same, > trzeba to wymusić. Najlepiej właśnie przez interaction workflow (w > projekcie niemieckim był w ogóle osobny workflow pt. > security_interaction_workflow, który był podpinany do każdego > portal_typu i jego interaction metod sprawdzało portal_type obiektu i > dokonywało stosownych czarów). O, właśnie. Ciekawe rozwiązanie, o którym nie wiedziałem, będę musiał się zastanowić :) (...) Podane przez Ciebie wytłumaczenia rozwiało wszystkie moje wątpliwości co do dynamiczności/statyczności definicji security na obiektach. Po prostu założę statyczność jeśli natrafię na "dziwne" zachowanie. Dzięki, Łukasz -- Łukasz Nowak R&D Ventis http://www.ventis.com.pl/ tel: +48 32 768 16 85 fax: +48 32 392 10 61 ``Use the Source, Luke...'' I am only craftsman.