From mashester w gmail.com Sat Jan 1 11:31:55 2011 From: mashester w gmail.com (Maciej Grzybek) Date: Sat, 01 Jan 2011 20:31:55 +0100 Subject: [Warszawa-pm] =?iso-8859-2?q?=5BCatalyst=5D_obs=B3uga_aktywacji_u?= =?iso-8859-2?q?=BFytkownika?= In-Reply-To: References: Message-ID: <4D1F812B.40603@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Witam, mam pytanie, prawdopodobnie do Zbyszka (gdyż problem dotyczy Catalysta), ale być może kto inny też będzie miał na to pomysł. ;) Mianowicie, chcę stworzyć pełny panel obsługi użytkownika pod nowy serwis. Do tej pory stworzyłem taką reprezentację: SQL: User: id,username,password,email,inne,bzdety Role: id,name User_Role: user_id,role_id Owa reprezentacja pozwala mi w łatwy sposób przydzielać uprawnienia użytkownikom. Dzięki relacji many-to-many mogę nadawać różne role (uprawnienia) poszczególnym użytkownikom. Problem pojawia się, gdy chcę zabezpieczyć rejestrację użytkownika mechanizmem aktywacji przez link w e-mailu. Zastanawiałem się jak to najlepiej zrobić. Pomysł jest trywialny i powszechnie stosowany (problem tylko z implementacją ;P): dodanie dwóch (ew. jednego) pól, np. activated (bool) oraz activation_code (varchar) wygenerowanie jakiegoś hasha, zapisanie go do bazy, po czym przesłanie do usera w mailu, wraz z linkiem, pod którym czaiłby się mechanizm, który w sprytny sposób zmieniałby activated na true, pod wpływem odpowiedniego activation_code, zgodnego z tym z bazy. Jednak, o ile ładnie mogę sobie aktywować użytkownika, to jak sprawdzić przy logowaniu, czy dany user jest aktywny? Loguję użytkownika w taki sposób: $c->authenticate({ username => $username,password => $password } ); gdzie $username i $password to odpowiednie wartości, wczytane z formularza logowania. Pierwszym pomysłem implementacji sprawdzania aktywacji było dodanie jeszcze jednego pola do sprawdzenia w metodzie authenticate, mianowicie: activated => 1. Jednak ten sposób nie pozwala mi na podanie użytkownikowi powodu, dla którego został odrzucony podczas logowania (czy podał złe hasło, czy nie ma aktywnego konta). Oczywiście można to obejść, robiąc dwa sprawdzenia (najpierw login + hasło, a później zapytanie o wartość activated i jeśli false to $c->logout), ale to chyba nie jest dobre rozwiązanie. Drugim pomysłem byłoby dodanie roli "activated", która nadawana byłaby każdego użytkownikowi, który dokonał aktywacji konta, ale wówczas w całym serwisie musiałbym sprawdzać $c->user_check_roles('activated'), a to wydaje mi się, mija się z celem. Jak to się robi profesjonalnie w Catalyście? Jest na to jakiś lepszy sposób? Póki co najrozsądniejszy wydaje mi się pierwszy (dodanie dodatkowego pola do sprawdzenia w metodzie authenticate), ale być może da się zrobić to lepiej. Za wszelkie sugestie z góry dziękuję i pozdrawiam, Maciek Grzybek -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNH4ErAAoJEJsau/Tq/KXRBecQAL+oTQMXWoFHSCdqcliEiuKj jsbSMEK2TPVuG2CBug6gN7FMhHIKtYFBA5DibctTpFb6U2imA4FilufdMsiBjqid IFMWwHCBbVOXJMatPROXX1E7HcW26XH6tfpsniaBQANgdqCCmmryhyaLjTZUI1pN IYoCNZmPDud3DO+59jOqcK0ae6AQNY+71yTulBVt06uHf4dKLzI/bo4L459B5os1 q6K3VyPNlKmRQ/IXKSZFcZoNGN3jZBrRrz21wWnTTlYm0M9LT0FTJ+dh1vHjHRDW +y90vv3botb7Ktte4zx8nuSBIWmpju+o4x6n+fIdiiTZkp+VVIErki1essb9KQDx iwcG8LHn3GkAh9k0iR3dHsvhoeExzLLHI1YGtRpat3rm4i4Z3B/N1ZeRAi6b7AQM w8If1Aky+x2OD5ScFUKQ8qY6CEu5VUWtvG6dIf/+CVqa+PQwIQd1TMrL7l2JUhs7 jfBFUmUS6xgdVub1rpWFK2Zq8nHWhSmzGuPlu9Ve1JGoc9T1gdfL1eAwTgzxsheC iJh9XWJoupMmEw1Ex9rOg/M5Kqt8mQo7ZuP0f3bhAlKSiYE+7mPXjMVOC986BuHW eF7sYJBZtCfYhFWtaeMnCqYaTZO51dPYfgM46x96LYgBLo0huq9HEKrBMie+WHLD 2TxH8LTOoXx5z8//q9OF =7nfz -----END PGP SIGNATURE----- From zzbbyy w gmail.com Sun Jan 2 01:54:42 2011 From: zzbbyy w gmail.com (Zbigniew Lukasiak) Date: Sun, 2 Jan 2011 10:54:42 +0100 Subject: [Warszawa-pm] =?utf-8?q?=5BCatalyst=5D_obs=C5=82uga_aktywacji_u?= =?utf-8?q?=C5=BCytkownika?= In-Reply-To: <4D1F812B.40603@gmail.com> References: <4D1F812B.40603@gmail.com> Message-ID: 2011/1/1 Maciej Grzybek : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Witam, > mam pytanie, prawdopodobnie do Zbyszka (gdyż problem dotyczy Catalysta), > ale być może kto inny też będzie miał na to pomysł. ;) > Mianowicie, chcę stworzyć pełny panel obsługi użytkownika pod nowy > serwis. Do tej pory stworzyłem taką reprezentację: > SQL: >        User: >                id,username,password,email,inne,bzdety >        Role: >                id,name >        User_Role: >                user_id,role_id > > Owa reprezentacja pozwala mi w łatwy sposób przydzielać uprawnienia > użytkownikom. Dzięki relacji many-to-many mogę nadawać różne role > (uprawnienia) poszczególnym użytkownikom. > Problem pojawia się, gdy chcę zabezpieczyć rejestrację użytkownika > mechanizmem aktywacji przez link w e-mailu. > Zastanawiałem się jak to najlepiej zrobić. Pomysł jest trywialny i > powszechnie stosowany (problem tylko z implementacją ;P): > dodanie dwóch (ew. jednego) pól, np. activated (bool) oraz > activation_code (varchar) wygenerowanie jakiegoś hasha, zapisanie go do > bazy, po czym przesłanie do usera w mailu, wraz z linkiem, pod którym > czaiłby się mechanizm, który w sprytny sposób zmieniałby activated na > true, pod wpływem odpowiedniego activation_code, zgodnego z tym z bazy. > Jednak, o ile ładnie mogę sobie aktywować użytkownika, to jak sprawdzić > przy logowaniu, czy dany user jest aktywny? > Loguję użytkownika w taki sposób: > $c->authenticate({ username => $username,password => $password } ); > gdzie $username i $password to odpowiednie wartości, wczytane z > formularza logowania. > Pierwszym pomysłem implementacji sprawdzania aktywacji było dodanie > jeszcze jednego pola do sprawdzenia w metodzie authenticate, mianowicie: > activated => 1. > Jednak ten sposób nie pozwala mi na podanie użytkownikowi powodu, dla > którego został odrzucony podczas logowania (czy podał złe hasło, czy nie > ma aktywnego konta). > Oczywiście można to obejść, robiąc dwa sprawdzenia (najpierw login + > hasło, a później zapytanie o wartość activated i jeśli false to > $c->logout), ale to chyba nie jest dobre rozwiązanie. > Drugim pomysłem byłoby dodanie roli "activated", która nadawana byłaby > każdego użytkownikowi, który dokonał aktywacji konta, ale wówczas w > całym serwisie musiałbym sprawdzać $c->user_check_roles('activated'), a > to wydaje mi się, mija się z celem. > Jak to się robi profesjonalnie w Catalyście? Jest na to jakiś lepszy > sposób? Póki co najrozsądniejszy wydaje mi się pierwszy (dodanie > dodatkowego pola do sprawdzenia w metodzie authenticate), ale być może > da się zrobić to lepiej. Niestety już dawno się tym nie zajmowałem. Może trzeba by po prostu dodać jedno sprawdzenie w kontrolerze (czy co tam obsługuje formularz login) - albo może użyć Realm (chociaż nigdy nie rozumiałem o co chodzi z tymi Realm i czym to się różni od roli). Pytanie jest czy authenticate nie powinno zwracać jakiegoś kodu przyczyny albo coś. Problem jest ciekawy (kiedyś będę się musiał zmierzyć z napisaniem bibliotek do autentykacji w WebNano - więc jestem bardzo zainteresowany rozwiązaniem go) i proponowałbym wysłać to na listę Catalysta. Pozdr. Zbyszek From mashester w gmail.com Sun Jan 2 03:23:33 2011 From: mashester w gmail.com (Maciej Grzybek) Date: Sun, 02 Jan 2011 12:23:33 +0100 Subject: [Warszawa-pm] =?iso-8859-2?q?=5BCatalyst=5D_obs=B3uga_aktywacji_u?= =?iso-8859-2?q?=BFytkownika?= In-Reply-To: References: <4D1F812B.40603@gmail.com> Message-ID: <4D206035.6000205@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 W dniu 02.01.2011 10:54, Zbigniew Lukasiak pisze: > Niestety już dawno się tym nie zajmowałem. Może trzeba by po prostu > dodać jedno sprawdzenie w kontrolerze (czy co tam obsługuje formularz > login) - albo może użyć Realm (chociaż nigdy nie rozumiałem o co > chodzi z tymi Realm i czym to się różni od roli). Pytanie jest czy > authenticate nie powinno zwracać jakiegoś kodu przyczyny albo coś. > Problem jest ciekawy (kiedyś będę się musiał zmierzyć z napisaniem > bibliotek do autentykacji w WebNano - więc jestem bardzo > zainteresowany rozwiązaniem go) i proponowałbym wysłać to na listę > Catalysta. > > > > Pozdr. > Zbyszek > _______________________________________________ > Warszawa-pm mailing list > Warszawa-pm w pm.org > http://mail.pm.org/mailman/listinfo/warszawa-pm > Realm? Wydaje mi się, że tego nie da się użyć przy tym problemie. Wg mnie najrozsądniej byłoby, gdyby authenticate zwracało kod błędu, na podstawie którego można byłoby wywnioskować co nie przypasowało do usera, aby go zalogować. W Catalyst Advent Calendar pisali o możliwości zrobienia czegoś takiego: sub login : Local { my ( $self, $c ) = @_; if ($c->authenticate( { username => $c->request->params->{'username'}, password => $c->request->params->{'password'}, status => [ 'registered', 'active' ] } )) { # display the login successful page here. } else { # display the 'try again' page here. } } gdzie array pełni rolę tablicy ORów (wystarczy by dowolny z warunków był spełniony), ale, jak wiadomo, nie jest to zadowalające, bo nie możemy sprawdzić, czy logowanie wysypało się na sprawdzeniu username + password czy na arrayu. Rozwiązaniem, które już byłoby zadowalające byłoby być może zwrócenie, który z argumentów nie pasował. Tylko jak to sprawdzić? Póki co na #catalyst @irc.perl.org nikt nie znalazł rozwiązania. ;) Pozdrawiam, Maciek Grzybek -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNIGA1AAoJEJsau/Tq/KXReRUQAK/IEetkH9Bq02MxpocXyukp M7ChAwNFCeOKU43yHXH00T5II0StojrO04sk4JhpMs/19A6DYdt+K07Hanzd4mAE qnlcF6VW7QUXO7VDPhoFFkB+aXe/31fHX3lG7vS/TCzxka70RS++Bi5KVtxT9sdU CVOnwr9g9Btstl02Blv4a4Fm6/3sOHG5mVeG31zbz5REXQZLcd8QOS2bzdLpw4z7 2xFVWYC7a2F4Un2KJ2Xc42FtfeR9X/SIFxfWte8xYVC/ysAuang3JBo7MH8jZgv6 huMEMdnGQzjw+xW4DdMoNiod+m/4o53/pamrtOgiWvApTJcwWqKXTcjOEmI94xCq YOOG7dmQL56hLiBDeRWqfuy0GnoUgCXuiFCTcbtToUG4gtJqOcEGNfbJajhJmYc9 h8twCGK5oSEV2xQ7TLKwRnoxlE5lhQk6y9t+OlXg1XR2LYmNxX1mV80SHfrMigp9 IXvfV0/2JcJqxiMhRW6KrlutJid9pmWVrp5xMOsmFUezBgpeiBQg22b9N45Sb80j eFg78IIwD4yNSyW23Ay4433klr6nkWi2ojq9pBJ7T2HTBUC+htf9RUdYGLLeHSdG TxLV6gBZBwlyUriXECkyloIRxQwgToF7MnLuGFjTztr4yJkoasXZ+/gbNWlA2YAq N/RNCfuIsAJtotPUelaN =qz1L -----END PGP SIGNATURE----- From zzbbyy w gmail.com Sun Jan 2 03:36:54 2011 From: zzbbyy w gmail.com (Zbigniew Lukasiak) Date: Sun, 2 Jan 2011 12:36:54 +0100 Subject: [Warszawa-pm] =?utf-8?q?=5BCatalyst=5D_obs=C5=82uga_aktywacji_u?= =?utf-8?q?=C5=BCytkownika?= In-Reply-To: <4D206035.6000205@gmail.com> References: <4D1F812B.40603@gmail.com> <4D206035.6000205@gmail.com> Message-ID: 2011/1/2 Maciej Grzybek : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > W dniu 02.01.2011 10:54, Zbigniew Lukasiak pisze: >> Niestety już dawno się tym nie zajmowałem.   Może trzeba by po prostu >> dodać jedno sprawdzenie w kontrolerze (czy co tam obsługuje formularz >> login) - albo może użyć Realm (chociaż nigdy nie rozumiałem o co >> chodzi z tymi Realm i czym to się różni od roli).  Pytanie jest czy >> authenticate nie powinno zwracać jakiegoś kodu przyczyny albo coś. >> Problem jest ciekawy (kiedyś będę się musiał zmierzyć z napisaniem >> bibliotek do autentykacji w WebNano - więc jestem bardzo >> zainteresowany rozwiązaniem go) i proponowałbym wysłać to na listę >> Catalysta. >> >> >> >> Pozdr. >> Zbyszek >> _______________________________________________ >> Warszawa-pm mailing list >> Warszawa-pm w pm.org >> http://mail.pm.org/mailman/listinfo/warszawa-pm >> > > Realm? Wydaje mi się, że tego nie da się użyć przy tym problemie. > Wg mnie najrozsądniej byłoby, gdyby authenticate zwracało kod błędu, na > podstawie którego można byłoby wywnioskować co nie przypasowało do > usera, aby go zalogować. > W Catalyst Advent Calendar pisali o możliwości zrobienia czegoś takiego: > >  sub login : Local { >     my ( $self, $c ) = @_; > >     if ($c->authenticate( { >                              username => > $c->request->params->{'username'}, >                              password => $c->request->params->{'password'}, >                              status => [ 'registered', 'active' ] >                           } )) { >        # display the login successful page here. >     } else { >        # display the 'try again' page here. >     } >  } > > gdzie array pełni rolę tablicy ORów (wystarczy by dowolny z warunków był > spełniony), ale, jak wiadomo, nie jest to zadowalające, bo nie możemy > sprawdzić, czy logowanie wysypało się na sprawdzeniu username + password > czy na arrayu. Rozwiązaniem, które już byłoby zadowalające byłoby być > może zwrócenie, który z argumentów nie pasował. Tylko jak to sprawdzić? > Póki co na #catalyst @irc.perl.org nikt nie znalazł rozwiązania. ;) No tak - z tym realm to chyba jednak nie. Ale może wystarczyłoby po prostu po if( $c->authenticate( $user, $password) ) dodać następny if sprawdzający czy $c->user jest 'active' i jeśli nie to po prostu wylogować go. Kody błędów byłyby na pewno lepszym rozwiązaniem - zastanawiam się tylko czy sprawdzanie 'active' na pewno należy do autentykacji. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/ From mashester w gmail.com Sun Jan 2 06:41:00 2011 From: mashester w gmail.com (Maciej Grzybek) Date: Sun, 02 Jan 2011 15:41:00 +0100 Subject: [Warszawa-pm] =?iso-8859-2?q?=5BCatalyst=5D_obs=B3uga_aktywacji_u?= =?iso-8859-2?q?=BFytkownika?= In-Reply-To: References: <4D1F812B.40603@gmail.com> <4D206035.6000205@gmail.com> Message-ID: <4D208E7C.9040503@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > No tak - z tym realm to chyba jednak nie. Ale może wystarczyłoby po > prostu po if( $c->authenticate( $user, $password) ) dodać następny if > sprawdzający czy $c->user jest 'active' i jeśli nie to po prostu > wylogować go. > > Kody błędów byłyby na pewno lepszym rozwiązaniem - zastanawiam się > tylko czy sprawdzanie 'active' na pewno należy do autentykacji. > Tak właśnie na początku pomyślałem (nawet w pierwszym mailu zaproponowałem takie rozwiązanie) i póki nie napotkam osoby, która pokaże mi lepsze rozwiązanie, tak zostawię w swojej aplikacji. ;) Co do przynależności 'active' do autentykacji, to wydaje mi się, że tak byłoby najwygodniej, ponieważ tylko raz sprawdzasz czy użytkownik został aktywowany, a później operujesz już na nim, jako poprawnie zalogowanym, gotowym do użytkowania serwisu. Poza tym, nawet Catalyst Advent Calendar mówi o sprawdzaniu wartości active/registered przy auth, tylko tamto rozwiązanie nie pozwala poprawnie zorganizować obsługi błędów logowania. Jeśli znajdę lepsze rozwiązanie, to zamailuję na listę. :) Pozdrawiam, Maciek Grzybek -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNII58AAoJEJsau/Tq/KXRXHQQAMqs/gR5Nt/UsB4CCsiX11yL yNd2msBo8biSu3fz/LOAK9Zxea1q7JrXPf0EjQlshhgFTZfGm5TmJCLLGu97f9H5 lPN8MOz2Z6/hmKzWmy3fd1NAqiA6upkWhcJtiVg+Q1q9Xm0eW4NcutcI6RpE0yeQ nasqpRTrmGDTcPFaCs1boAWBn9azTcnFim05ckhXhrEYvudqKLhA3KznY8ba+ZvR A0nKD948cucixjrca+j9rVSZoXqemBQvA4bG0umWVYOPzUWxg0TknVimqiTlm1iV tmttU3mwAb7qnD8g5ASLZgbz0SXtHpF5bDN3vxLpN5/RwlzCrgK//Toj823HrYzW 4HqLDXlSJCaSb7vWcy/pNB2w2JxRK4zkzs1GaCrqKfQ1UFgc700eagAgwCDe3NHO MruEE8RwgW2nOt6a/KotFcvgwBMLiRCv2QpJqECVRQHjfn7pY0e2wSe/WZjX7tFw Sn6leydCPcoy49YZnbvUJHxPXvJ3GsTKOwR3pICVm8uLB4WpQR/xAGuqpid85M+B GYeK/Jp+yTTXSS3tg++CZPZEyXjJsM+KgiDXNK5GNdCqk/v4SL3sysmLq5KIxZnu PISE1Mdlj/7qEGWB9o+Lo9Oi4q5P4yBXBFOuYJPkD/V5Khp9CvjM+LyTtXquSyLk LBVpDJ/1Vg8XIon8LpsX =vswU -----END PGP SIGNATURE----- From mashester w gmail.com Sun Jan 2 08:21:07 2011 From: mashester w gmail.com (Maciej Grzybek) Date: Sun, 02 Jan 2011 17:21:07 +0100 Subject: [Warszawa-pm] =?iso-8859-2?q?=5BCatalyst=5D_obs=B3uga_aktywacji_u?= =?iso-8859-2?q?=BFytkownika?= In-Reply-To: References: <4D1F812B.40603@gmail.com> <4D206035.6000205@gmail.com> Message-ID: <4D20A5F3.3010204@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Witam, zgodnie z obietnicą, przesyłam czego się dowiedziałem w sprawie autentykacji i sprawdzania aktywacji użytkownika. Na #catalyst (@irc.perl.org), powiedziano mi, że sprawdzenie tego czy użytkownik jest activated to nie zadanie mechanizmu autentykacji. Należy to rozwiązać albo poprzez role (jeśli nieaktywowany użytkownik może cokolwiek robić w serwisie, np. przesłać sobie ponownie kod aktywujący), które będziemy sprawdzać w metodzie auto, razem z if($user_exists), albo bez roli, ale też sprawdzając w ten sam sposób (w metodzie auto) poprzez $c->user->get('activated'). Może i to jest jakieś rozwiązanie, aczkolwiek gdyby $c->authenticate(), zwracał który parametr mu nie przypasował do użytkownika, byłoby to naprawdę przydatne (o ile da się to w obecnym mechanizmie autentykacji zaaplikować). Jeśli, Zbyszku, będziesz zabierał się za pisanie modułu autentykacji do WebNano, to bardzo chętnie wezmę udział w dyskusji na ten temat, jeśli zechcesz taką w ogóle otworzyć. Wydaje się, że można znaleźć wiele dróg rozwiązania tego problemu, ale każdy z nich narzuca pewne ścieżki rozwoju aplikacji. Pozdrawiam, Maciek Grzybek -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNIKXzAAoJEJsau/Tq/KXRu04P/jQlnaAhJ2rTgv0uhRRBysfq OfQkbCOmy/l9KLgfvpg639iMfA6vPqvviySioJP8BGNjZQaoTkquS+YlPNjq1tPy I0kAi7Gl9Iw1J1vtHkVcQH2IzxpVLXdpTFZ1pywdVaomR1QMKXTD8x09dbvIinWd F/fxdCCe1dbSudhpHXPMvoCIwWEwHdXPLILJCPwSXu8vDyejpe8v4a0hwK5XnHoR aX/m9ug9dA/566SL6SQ4o8NFPz805yH9JnFN5NWKWC5OU6sJc8szTql+pUmYjmzp hzO7LHSmG3xQttgpuAvuBjscpnJxXu1yDkysm73LgRYOZlbahp1efLyWiXSuKUBm CbNhVkSgFMBgBYFHCOMmVhmPLwVLFaqwumuOqWCeL4Z/arhPFQ+YvVLL6TmEjjz4 /uKakmCXRV91CuK1i0uxJdGwbRnDCG7npuZQvrqR3Gu8qEpZs/Rje9n+gM3GbNZd ff4pA7say8fRVkKboNC4KjO9Y1NUxHVY90bSZAQUsxstFdjLm7ve8gTyC6SeBnTX HQ1b/oW9KFMyPf6PCtBTnIx2nUfSdI5qvSeis7ZsprXPJbdferAjSa0OQwsTIjwt t8DyK2GtYwm6XMdn49c/h3NyphlCiZugIfm6428Y6Sz7YWBYSajBwNjo5IW7MQmj LWj6S9oLDL3lnryYjqLK =JNfH -----END PGP SIGNATURE----- From zzbbyy w gmail.com Sun Jan 2 12:04:39 2011 From: zzbbyy w gmail.com (Zbigniew Lukasiak) Date: Sun, 2 Jan 2011 21:04:39 +0100 Subject: [Warszawa-pm] =?utf-8?q?=5BCatalyst=5D_obs=C5=82uga_aktywacji_u?= =?utf-8?q?=C5=BCytkownika?= In-Reply-To: <4D20A5F3.3010204@gmail.com> References: <4D1F812B.40603@gmail.com> <4D206035.6000205@gmail.com> <4D20A5F3.3010204@gmail.com> Message-ID: 2011/1/2 Maciej Grzybek : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Witam, zgodnie z obietnicą, przesyłam czego się dowiedziałem w sprawie > autentykacji i sprawdzania aktywacji użytkownika. > Na #catalyst (@irc.perl.org), powiedziano mi, że sprawdzenie tego czy > użytkownik jest activated to nie zadanie mechanizmu autentykacji. Należy Też myślałem tak jak oni - ale: 1. Można sobie wyobrazić systemy gdzie autentykacja jest stopniowa. Właściwie wiele dużych systemów już to stosuje Amazon czy LinkedIn każą się drugi raz zalogować jeśli trzeba zrobić coś ważnego a Ty autentykowałeś się przez sesję - w takim przypadku też przydałyby się jakieś kody. 2. Problem tak naprawdę leży w tym, że authenticate nie tylko autentykuje ale też loguje do systemu. Jeśli ktoś poda prawidłowe hasło dla nieaktywnego użytkownika to można się zgodzić, że jest zautentykowany, ale $c->user nie powinno być ustawione. A co do autentykacji w WebNano to zastanawiam się nad czymś bardziej ogólnym. Kiedyś się pytałem Miyagawy co myśli na temat middleware do autentykacji - ale jemu się nie podoba ten pomysł i uważa, że autentykacja powinna być częścią frejmłorku. Może potrzebny jest jakiś pomysł na komponent do Placka który niekoniecznie jest Middleware - ale tak samo jak Middleware może być używany przez różne frejmłorki. Chyba wielu ludzi o tym myśli - na przykład http://twitter.com/#!/clkao/status/27613002311 Z. From pp w pietrek.priv.pl Mon Jan 3 02:52:11 2011 From: pp w pietrek.priv.pl (p p) Date: Mon, 3 Jan 2011 11:52:11 +0100 Subject: [Warszawa-pm] =?iso-8859-2?q?=5BCatalyst=5D_obs=B3uga_aktywacji_u?= =?iso-8859-2?q?=BFytkownika?= In-Reply-To: References: <4D1F812B.40603@gmail.com> <4D206035.6000205@gmail.com> <4D20A5F3.3010204@gmail.com> Message-ID: > > 2. Problem tak naprawdę leży w tym, że authenticate nie tylko > autentykuje ale też loguje do systemu. Jeśli ktoś poda prawidłowe > hasło dla nieaktywnego użytkownika to można się zgodzić, że jest > zautentykowany, ale $c->user nie powinno być ustawione. > > > zgadzam sie w Catalyst::Plugin::Authentication jest The next logical step is authorization, the process of deciding what a user is (or isn't) allowed to do. For example, say your users are split into two main groups - regular users and administrators. You want to verify that the currently logged in user is indeed an administrator before performing the actions in an administrative part of your application. These decisions may be made within your application code using just the information available after authentication, or it may be facilitated by a number of plugins. czyli po authentication trzeba jeszcze np sprawdzic czy konto nie wygaslo (jesli aplikacja ma taka strukture), czy np nie jest aktywna sesja z innego adresu IP (jesli jest wyamganie jednej sesji). i jak cos jest nie tak zrobic $c->logout zreszta moze byc wymog aby takie sprawdzania (waznosci konta) robic przy kazdym requescie - a sprawdzanie hasla tylko przy logowaniu. taka logika moze sie zmieniac w zaleznosci od innych danych aplikacji authentication (sprawdznie user-paswsword) jest na tyle uniwersalne, ze mozna napisac ogolny modul dodatkowe warunki (authorization) okresla biznes i to juz jest wolna amerykanka authenticatuion to tylko sprawdzenie tozsamosci - nic wiecej - nie nalezy tam pchac nic wiecej. oczywiscie bezpieczniej byloby zrobic $user=$c->authenticate(...) if($user and $user->isactive ...){ $c->login($user) }else{ $c->stash->{msg}='konto nieaktywne...' } niz jak jest teraz w catalyscie $c->authenticate unless($c->user and $c->user->isactive...){ $c->logout $c->stash->{msg}='konto nieaktywne...' } trzeba sie pogodzic, autorzy maja inna filozowfie tu i w kilku innych miejscach i szkoda czasu na ronieniee lez. jak nie pasuje, napisac wlasny frejmlork, bo mowimy o fundamentalnych zmianach - fundamenty ciezko zmienic -- pp -------------- następna część --------- Załącznik HTML został usunięty... URL: From mashester w gmail.com Mon Jan 3 04:53:29 2011 From: mashester w gmail.com (Maciej Grzybek) Date: Mon, 03 Jan 2011 13:53:29 +0100 Subject: [Warszawa-pm] =?iso-8859-2?q?=5BCatalyst=5D_obs=B3uga_aktywacji_u?= =?iso-8859-2?q?=BFytkownika?= In-Reply-To: References: <4D1F812B.40603@gmail.com> <4D206035.6000205@gmail.com> <4D20A5F3.3010204@gmail.com> Message-ID: <4D21C6C9.5080402@gmail.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 W dniu 02.01.2011 21:04, Zbigniew Lukasiak pisze: > 2. Problem tak naprawdę leży w tym, że authenticate nie tylko > autentykuje ale też loguje do systemu. Jeśli ktoś poda prawidłowe > hasło dla nieaktywnego użytkownika to można się zgodzić, że jest > zautentykowany, ale $c->user nie powinno być ustawione. Zgadzam się z tym, nie powinniśmy skazywać użytkownika na tylko jedną drogę rozwoju aplikacji. Wystarczyłoby, aby programista sam ustawiał $c->login; jeśli autentykacja przebiegła prawidłowo. Dałoby to większą swobodę (można przy okazji autentykacji sprawdzić user->isactive user->isntexpired itd. itd., w zależności od potrzeb). Rozwiązanie z $c->logout, w przypadku gdy coś nie pasuje (active, expiration etc.), jest workaroundem wg mnie. > A co do autentykacji w WebNano to zastanawiam się nad czymś bardziej > ogólnym. Kiedyś się pytałem Miyagawy co myśli na temat middleware do > autentykacji - ale jemu się nie podoba ten pomysł i uważa, że > autentykacja powinna być częścią frejmłorku. Może potrzebny jest > jakiś pomysł na komponent do Placka który niekoniecznie jest > Middleware - ale tak samo jak Middleware może być używany przez różne > frejmłorki. Chyba wielu ludzi o tym myśli - na przykład > http://twitter.com/#!/clkao/status/27613002311 > > > Z. Autentykacja jest na zbyt wysokim poziomie i zależy od logiki aplikacji (co było widać choćby na przykładzie tej krótkiej wymiany zdań). Moim zdaniem nie powinna być na poziomie Plack'a, który powinien oferować nam dostęp do mechanizmów, a nie do gotowych rozwiązań, zależnych od konkretnej logiki aplikacji. W sytuacji, gdy będziemy za dużo narzucać, stanie się tak jak z $c->authenticate() w Catalyscie. Zbyszku, mam do Ciebie też inne pytanie/prośbę. Widziałem Cię w sekcji Contributors w HTML::FormHandler. Przepatrywałem źródła w poszukiwaniu możliwości customizowania message'ów wyświetlanych, gdy coś się nie powiodło z danym fieldem. Zauważyłem, że Fields/Password.pm ma hardcode'owany msg w przypadku, gdy username jest taki sam jak hasło: return $self->add_error( 'Password must not match ' . $self->ne_username ) if $username && $username eq $value; Wydaje mi się, że powinno to być customizowalne, tak jak w innych Fieldach, np. jak w PasswordConf. Wystarczyłoby dodać: has 'ne_username_message' => ( isa => 'Str', is => 'rw', default => 'Password must not match username' ); i zmienić tę linię: return $self->add_error( 'Password must not match ' . $self->ne_username ) if $username && $username eq $value; na return $self->add_error( $self->ne_username_message ) if $username && $username eq $value; Ponadto wydaje mi się, że warto ujednolicić system nazw tych message'ów, gdyż np. w PasswordConf'ie, nazwa: pass_conf_message, jest trochę nieintuicyjna. Pierwsze skojarzenie to "message", może tak byłoby lepiej? Mam gdzieś przesłać patcha na tego PasswordConf'a, czy Ty już to wrzucisz? Pozdrawiam, Maciej 'mac' Grzybek -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJNIcbJAAoJEJsau/Tq/KXRZ+MQAMMjqYSvZ7Y/MtgprrLWEyDN Y7MTbtPD9KZx56gGOiGC3sevjhYJh6KRFb49NYJaeNjZZmpMO/V4Qld5rJzJ9fMh 9R/0NorrQhycI6BrLp0+LuChy6k/uwT+2tcjRX8jEFySGI4ywG/hvIqT7w/CGpgs dqfGglx9CQC0Xr+kAH225xo1HJ0KLlAA9bW8o+klyE1ziO1PwKWqFN/rGKA7zNO/ /4pvbDhEIceFZTQy6zeUD20L3Zxtr/ZPfrohZnfdH+LZQ7ZtYJx9nJnpD22txWZQ a0Cw7T0kulT85KxEolEOHm9Hm9jpP2dm2SHgtCef1aFHBeZto2RyB0d9BfcBdZ8x aK4SLsfMMBN2B4m6uvRz4gKG99fHdUmp38S2Ny9mVQyarXw802LBNmYpmOMwWgqA SJeAHq/C+8oOS1WaRbKBPTE1GLSQN0sGHHvEOQ38h5rAY/COLSTsz1pOU1O3uzJ9 waJNWe50XXRUNYfD2CtA2Ir2FVBrCBykYtqIix4Hhp/bgY4rnup41ajYpVtMkWMx odg8319JpiaDZdTyoaScYQjFiDq4hm3eFxXqGDR8mLaO4xqzdzYvQYzFjZOOFGNx OZoy/7SqVKUcWPqiFDjbuOFJzqAvv2S8aZWogDq6lFAp0nr3gJKWSqMR/tSThrue ev6zHytCYhhzHEN50lsO =u+ki -----END PGP SIGNATURE----- From zzbbyy w gmail.com Mon Jan 3 23:24:35 2011 From: zzbbyy w gmail.com (Zbigniew Lukasiak) Date: Tue, 4 Jan 2011 08:24:35 +0100 Subject: [Warszawa-pm] =?utf-8?q?=5BCatalyst=5D_obs=C5=82uga_aktywacji_u?= =?utf-8?q?=C5=BCytkownika?= In-Reply-To: <4D21C6C9.5080402@gmail.com> References: <4D1F812B.40603@gmail.com> <4D206035.6000205@gmail.com> <4D20A5F3.3010204@gmail.com> <4D21C6C9.5080402@gmail.com> Message-ID: 2011/1/3 Maciej Grzybek : > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > W dniu 02.01.2011 21:04, Zbigniew Lukasiak pisze: >> 2. Problem tak naprawdę leży w tym, że authenticate nie tylko >> autentykuje ale też loguje do systemu.  Jeśli ktoś poda prawidłowe >> hasło dla nieaktywnego użytkownika to można się zgodzić, że jest >> zautentykowany, ale $c->user nie powinno być ustawione. > > Zgadzam się z tym, nie powinniśmy skazywać użytkownika na tylko jedną > drogę rozwoju aplikacji. Wystarczyłoby, aby programista sam ustawiał > $c->login; jeśli autentykacja przebiegła prawidłowo. > Dałoby to większą swobodę (można przy okazji autentykacji sprawdzić > user->isactive user->isntexpired itd. itd., w zależności od potrzeb). > Rozwiązanie z $c->logout, w przypadku gdy coś nie pasuje (active, > expiration etc.), jest workaroundem wg mnie. OK - chyba wszyscy się zgadzają tutaj. Ale teraz pytanie co zrobić w czymś takim jak SimpleLogin - który ma dawać jakiś w miarę uniwersalny mechanizm? Na pewno musi on również wlogowywać - więc jak to zrobić, żeby to się dało później zmienić jak dochodzą takie dodatkowe warunki? Pewnie trzeba zrobić jakąś metodę którą się łatwo 'override'. Z. From pp w pietrek.priv.pl Tue Jan 4 02:33:15 2011 From: pp w pietrek.priv.pl (p p) Date: Tue, 4 Jan 2011 11:33:15 +0100 Subject: [Warszawa-pm] =?iso-8859-2?q?=5BCatalyst=5D_obs=B3uga_aktywacji_u?= =?iso-8859-2?q?=BFytkownika?= In-Reply-To: References: <4D1F812B.40603@gmail.com> <4D206035.6000205@gmail.com> <4D20A5F3.3010204@gmail.com> <4D21C6C9.5080402@gmail.com> Message-ID: > > > OK - chyba wszyscy się zgadzają tutaj. Ale teraz pytanie co zrobić w > czymś takim jak SimpleLogin - który ma dawać jakiś w miarę uniwersalny > mechanizm? Na pewno musi on również wlogowywać - więc jak to zrobić, > żeby to się dało później zmienić jak dochodzą takie dodatkowe warunki? > Pewnie trzeba zrobić jakąś metodę którą się łatwo 'override'. > > ja bym robil tak $c->authenticator(My::Authen->new()) $user=$c->authenticate(user=>user, password=>password,extra=>{other=>data}) if($c->user->isactive){ $c->login($user); } user, password - obowiazkowe extra - miejsce na dodatkowe dane dla bardziej specyficznych metod autentykacji musi byc jasna specyfiakacja jakie funkcje musi realizowac obiekt My::Authen->new() i z jakimi parametrami takie funkcje beda wywolywane wewnatrz frejmlorkowego procesu. ja wybieram motody autentykacji tworzac odpowiedni obiekt i przekazujac do frejmlorku, frejmlork robi to co mu potrzebne - nie musze o tym wiedziec co robi frejmlork, jedyne to musze dac obiekt, o odpowiedniej specyfikacji -- pp -------------- następna część --------- Załącznik HTML został usunięty... URL: From zzbbyy w gmail.com Wed Jan 5 10:44:44 2011 From: zzbbyy w gmail.com (Zbigniew Lukasiak) Date: Wed, 5 Jan 2011 19:44:44 +0100 Subject: [Warszawa-pm] Spotkanie styczniowe? Message-ID: Hej! Jak tam - organizujemy te regularne spotkania w ostatni czwartek - czy jak dotychczas glosujemy? Przy okazji jestem bardzo zadowolony z mojego ostatniego artykulu na blogu: http://perlalchemy.blogspot.com/2011/01/dependency-injection-or-removing.html . Liczę na komentarze. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/ From wb w sao.pl Thu Jan 6 10:38:05 2011 From: wb w sao.pl (Waldemar Biernacki) Date: Thu, 6 Jan 2011 19:38:05 +0100 Subject: [Warszawa-pm] =?utf-8?q?Napisa=C5=82em_program?= Message-ID: <201101061938.05750.wb@sao.pl> Hej! Napisałem source editor Yase - szczególnie do tworzenia i rozwijania bazy danych SQL (PostgreSQL). Info o programie jest tutaj: http://source.sao.pl/source?item=200 tam też jest dostępny zip file z kodem Perla (5.10) i całą strukturą katalogów. Dla Windows jest też wersja wrap yase.exe spakowane przez narzędzie Activestate. Program działa w linuksie i Windows identycznie (z dokładnoścuią do drobnych różnic w dekoracji i inaczej przeliczanych rozmiarów czcionek). Cechy główne to: Działa identycznie w Windows i Linux. Jest mały i nie oprócz wgrania katalogu nie potrzebuje (chyba, że doinstalowania modułów Perla - zwłaszcza modułu graficznego Prima) Drzewo katalogów i plików. Tylko pliki o wskazanym rozszerzeniu. Projekt może skłądać się z wielu niezależnych katalogów root. Każde rozszerzenie ma definiowaną w perlu składnie (regexp). Można łatwo definiować własne podświetlanie własnych lub znanych typów. Np standardowy SQL ma zwykle słabe podświetlanie (wg mnie powinien lepiej rozróżniać kod SQL od kodu funkcji składowanych). Można wyeksportować kolorowany html Można obsługiwać duże pliki (sprawdzałem rzędu 100MB sql). Zachęcam do pobrania - a nuż taka idea edytaora komuś z Was się spodoba... Bardzo chętnie wysłucham uwag. wb. From tadzikes w gmail.com Sat Jan 8 09:19:28 2011 From: tadzikes w gmail.com (Tadeusz =?utf-8?B?U2/Fm25pZXJ6?=) Date: Sat, 8 Jan 2011 18:19:28 +0100 Subject: [Warszawa-pm] Spotkanie styczniowe? In-Reply-To: References: Message-ID: <20110108171928.GC5848@yavin4> On 5-01-2011 19:44:44, Zbigniew Lukasiak wrote: > Hej! > > Jak tam - organizujemy te regularne spotkania w ostatni czwartek - czy > jak dotychczas glosujemy? Hej, Ja bym głosował, ostatni czwartek jest już niebezpiecznie blisko sesji ;) > > Przy okazji jestem bardzo zadowolony z mojego ostatniego artykulu na > blogu: http://perlalchemy.blogspot.com/2011/01/dependency-injection-or-removing.html > . Liczę na komentarze. Ciekawe. Skomentować może nie skomentuję, za dużo w temacie do dodania nie mam, ale teoria wydaje się być rozsądna i fajnie opisana. Dzięki! Pozdrawiam, Tadek From piotr.roszatycki w gmail.com Sat Jan 8 12:45:08 2011 From: piotr.roszatycki w gmail.com (Roszatycki, Piotr) Date: Sat, 8 Jan 2011 21:45:08 +0100 Subject: [Warszawa-pm] Dependency Injection Message-ID: W dniu 5 stycznia 2011 19:44 użytkownik Zbigniew Lukasiak napisał: > Przy okazji jestem bardzo zadowolony z mojego ostatniego artykulu na > blogu: > http://perlalchemy.blogspot.com/2011/01/dependency-injection-or-removing.html > . Liczę na komentarze. Czekaj, czekaj... Czy to chodzi o to, aby nie tworzyć obiektów w danej klasie tylko przekazywać je za pomocą parametru konstruktora tej klasy albo settera? Rany... Ta prosta reguła ma swoją nazwę, dziesiątki publikacji oraz nawet dedykowane biblioteki ( http://components.symfony-project.org/dependency-injection/)? Myślę, że kogoś pogięło, bo to typowy przerost formy nad treścią ;) Nota bene, w Perlu jest ciekawa tego implementacja: http://search.cpan.org/perldoc?Bread::Board Wydaje mi się, że całość tego tematu sprowadza się do wyboru, czy hardkodowane parametry zapisujemy w pliku konfiguracyjnym (XML, jak to się chyba odbywa w Java Spring), czy w natywnym języku (wszystkie obiekty tworzone w głównej funkcji) lub też skorzystanie z jakiegoś specjalizowanego języka (Bread::Board). -- .''`. Piotr Roszatycki : :' : mailto:Piotr.Roszatycki w gmail.com `. `' mailto:dexter w debian.org `- -------------- następna część --------- Załącznik HTML został usunięty... URL: From zzbbyy w gmail.com Sat Jan 8 13:17:31 2011 From: zzbbyy w gmail.com (Zbigniew Lukasiak) Date: Sat, 8 Jan 2011 22:17:31 +0100 Subject: [Warszawa-pm] Dependency Injection In-Reply-To: References: Message-ID: 2011/1/8 Roszatycki, Piotr : > W dniu 5 stycznia 2011 19:44 użytkownik Zbigniew Lukasiak > napisał: >> >> Przy okazji jestem bardzo zadowolony z mojego ostatniego artykulu na >> blogu: >> http://perlalchemy.blogspot.com/2011/01/dependency-injection-or-removing.html >> .  Liczę na komentarze. > > Czekaj, czekaj... > Czy to chodzi o to, aby nie tworzyć obiektów w danej klasie tylko > przekazywać je za pomocą parametru konstruktora tej klasy albo settera? > Rany... Ta prosta reguła ma swoją nazwę, dziesiątki publikacji oraz nawet > dedykowane biblioteki > (http://components.symfony-project.org/dependency-injection/)? Myślę, że > kogoś pogięło, bo to typowy przerost formy nad treścią ;) Tak - to o to chodzi, jednak nie uważam, że to jest przerost formy nad treścią - bo jednak "prosta reguła, by nie tworzyć obiektów w danej klasie tylko przekazywać je za pomocą parametru konstruktora tej klasy albo settera" jest nieco za długie, a trzeba to jakoś nazwać. A trzeba to jakoś nazwać, bo chociaż jest to dość naturalne - to jenak jest mnóstwo kodu który tą regułę łamie. To jest trochę tak jak ze zmiennymi globalnymi. Niby prosta sprawa, ale jednak trochę trwało, żeby zostało ogólnie zaakceptowane, że to jest niedobre. A co jakby to jeszcze nie miało nazwy? Oczywiście nazwa jest raczej kiepska bo rzeczywiście sugeruje niewiadomo co - podczas gdy sprawa jest prosta. Chociaż nie znaczy to, że wokół niej nie ma ciekawych problemów. > Nota bene, w Perlu jest ciekawa tego > implementacja: http://search.cpan.org/perldoc?Bread::Board > Wydaje mi się, że całość tego tematu sprowadza się do wyboru, czy > hardkodowane parametry zapisujemy w pliku konfiguracyjnym (XML, jak to się > chyba odbywa w Java Spring), czy w natywnym języku (wszystkie obiekty > tworzone w głównej funkcji) lub też skorzystanie z jakiegoś specjalizowanego > języka (Bread::Board). No i właśnie - wbrew temu co sugerujesz nie jest to wcale prosty wybór - dobry język tutaj to jest wszystko. Poza tym to co robi Bread::Board i inne 'container'y to jest nie tylko specjalizowany język (na przykład XML) - ale też 'rozwiązywanie grafu' zależności - jeśli z 'containera' wyciągasz jakiś objekt to on już sam tworzy wszystkie jego zależności - nie musisz tego kodować sam. Ale do samego DI nie musisz tego używać i sobie kodować to ręcznie. Poza tym dochodzi jeszcze sprawa tego ile takich 'factories' czy 'containers' masz w aplikacji - to wcale nie jest prosta sprawa. Wydaje mi się, że jest potrzebna jedna na każdy 'scope'. Czasem proste reguły generują ciekawe problemy. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/ From piotr.roszatycki w gmail.com Sat Jan 8 14:07:20 2011 From: piotr.roszatycki w gmail.com (Roszatycki, Piotr) Date: Sat, 8 Jan 2011 23:07:20 +0100 Subject: [Warszawa-pm] Dependency Injection In-Reply-To: References: Message-ID: W dniu 8 stycznia 2011 22:17 użytkownik Zbigniew Lukasiak napisał: > klasy albo settera" jest nieco za długie, a trzeba to jakoś nazwać. A > trzeba to jakoś nazwać, bo chociaż jest to dość naturalne - to jenak > jest mnóstwo kodu który tą regułę łamie. To jest trochę tak jak ze > zmiennymi globalnymi. Niby prosta sprawa, ale jednak trochę trwało, > żeby zostało ogólnie zaakceptowane, że to jest niedobre. A co jakby > to jeszcze nie miało nazwy. > Haha, wystarczy dać nazwę i już mamy niszę do zagospodarowania na rynku softwarowym :) Oczywiście nazwa jest raczej kiepska bo rzeczywiście sugeruje > niewiadomo co - podczas gdy sprawa jest prosta. Chociaż nie znaczy > to, że wokół niej nie ma ciekawych problemów. > O dokładnie. To chyba ciekawe narzędzie w przypadku, gdy nie panujemy już nad kodem i/lub zależy nam na ścisłej enkapsulacji. Dla małych projektów to chyba armata na muchę, a dla większych to i tak pakujemy się w kłopoty z wzajemnymi zależnościami (np. logowanie do bazy: najpierw obiekt Log czy obiekt Database?) Idąc tą drogą dalej to nie trzeba w ogóle kodować, a wystarczyłoby tylko łączyć klasy za pomocą jakiegoś graficznego narzędzia w stylu Simulink :) I pomysleć, że to wszystko po to, aby gdzieś w jakiejś klasie nie było hardkoda ;) -- .''`. Piotr Roszatycki : :' : mailto:Piotr.Roszatycki w gmail.com `. `' mailto:dexter w debian.org `- -------------- następna część --------- Załącznik HTML został usunięty... URL: From magik w roorback.net Sat Jan 8 14:39:41 2011 From: magik w roorback.net (Grzegorz Blach) Date: Sat, 8 Jan 2011 23:39:41 +0100 Subject: [Warszawa-pm] Dependency Injection In-Reply-To: References: Message-ID: Swoją drogą, ciekawe czy już ktoś opatentował tą rewelacyjną technologię? Bo znając amerykańców, to zaraz ruszy seria pozwów o naruszenie patentu. From piotr.roszatycki w gmail.com Wed Jan 12 04:00:36 2011 From: piotr.roszatycki w gmail.com (Roszatycki, Piotr) Date: Wed, 12 Jan 2011 13:00:36 +0100 Subject: [Warszawa-pm] Kwartz In-Reply-To: References: Message-ID: Hej. Co do rozdzielania logiki, to konkretne kolory są danymi (składowe RGB na przykład) ale to, że chcesz tabelkę podzielić np. na pasy jasne i ciemne, albo wartości ujemne oznaczyć innym kolorem niż wartości dodatnie, to już jest jak najbardziej logika prezentacji. Być może to jest przekombinowane, ale elegancji założeniu się nie da odmówić. Inna sprawa, że Kwartz to raczej ciekawa implementacja w stylu "proof of concept" i żywcem na Perla bym jej nie portował. Co do takiego dziedziczenia szablonów to jest to wbudowane w moduł http://search.cpan.org/perldoc?ASP4 Jak pamiętasz, to ja nie jestem za bardzo zwolennikiem MVC i do swoich rzeczy to raczej technologii ASP używam. Akurat ASP4 jest dość fajną implementacją i dopasowaną do nowych Perlowych zabawek (PSGI). Przyuważ dokumentację http://search.cpan.org/perldoc?ASP4::MasterPage Z niej wynika, że tam zaimplemetowane jest prawdziwe dziedziczenie szablonów (use base)! Mnie brakuje jeszcze ciekawych mechanizmów OO z Moose (before/after, augment/inner). Gdyby tak połączyć pewne rozwiązania z ASP4 i Kwartza, to dla mnie była by bomba :) W dniu 11 stycznia 2011 19:47 użytkownik Zbigniew Lukasiak napisał: > Hej! > > Ciekawy pomysł nie powiem - ale żeby wyrobić sobie zdanie to musiałbym > trochę poużywać w praktyce. > Jedna uwaga - ostani przykład na > http://www.kuwata-lab.com/kwartz/kwartz3ruby-users-guide.01.html#intro > - piszą o całkowitym rozdzieleniu logiki od danych - ale kolory to są > dane nie? Zresztą może to rozdzielenie to już przekombinowane jest? > > A gdzie tam jest o tym inheritance? > > Najlepiej odpisz na listę - może się ktoś włączy. > > Pozdrawiam, > Z. > -- .''`. Piotr Roszatycki : :' : mailto:Piotr.Roszatycki w gmail.com `. `' mailto:dexter w debian.org `- -------------- następna część --------- Załącznik HTML został usunięty... URL: From zzbbyy w gmail.com Sun Jan 16 09:57:30 2011 From: zzbbyy w gmail.com (Zbigniew Lukasiak) Date: Sun, 16 Jan 2011 18:57:30 +0100 Subject: [Warszawa-pm] =?utf-8?q?Og=C5=82oszenie?= Message-ID: http://www.goldenline.pl/forum/2174066/zlecenie-w-perlu Podoba mi się :) Chociaż na konkretne pieniądze to bym za to nie liczył. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/ From tadzikes w gmail.com Tue Jan 18 11:23:52 2011 From: tadzikes w gmail.com (Tadeusz =?utf-8?B?U2/Fm25pZXJ6?=) Date: Tue, 18 Jan 2011 20:23:52 +0100 Subject: [Warszawa-pm] YAPC::EU 2011 Message-ID: <20110118192352.GA5270@yavin4.chomiczowka.waw.pl> Hej, Rejestrować się już można[1], wybiera się ktoś? Pozdrawiam, Tadek [1] http://yapceurope.lv/ye2011/ From piotr w fusik.info Tue Jan 18 14:59:34 2011 From: piotr w fusik.info (=?UTF-8?B?UGlvdHIgRnVzaWs=?=) Date: Tue, 18 Jan 2011 23:59:34 +0100 Subject: [Warszawa-pm] YAPC::EU 2011 Message-ID: <73e4ac50b7f8590974d1446e01e8d770.qmail@home.pl> >Rejestrować się już można[1], wybiera się ktoś? >[1] http://yapceurope.lv/ye2011/ Zastanawiam się. Będzie Larry? Pozdrawiam, Piotr From michael w zedeler.dk Thu Jan 20 22:35:45 2011 From: michael w zedeler.dk (Michael Zedeler) Date: Fri, 21 Jan 2011 07:35:45 +0100 Subject: [Warszawa-pm] Job posting: senior perl developer - full time permanent position Message-ID: <4D392941.6000202@zedeler.dk> Hi. I am currently looking for a senior perl developer for a small team working on a Catalyst based web application using CouchDB as datastore. We are based in Copenhagen and suggest that any interested candidates can work from home with the opportunity to relocate to Denmark. The job has the following requirements: * 5+ years experience with software or systems development. * Used to do OOP, OOA and OOD. Having experience with the following would be an advantage: * Any agile development method (Scrum , TDD, XP and others). * Read, write and speak Danish. * Git. * Perl 5 - especially: o Catalyst o Moose * XSLT * CouchDB * JavaScript - especially: o JSON o Dojo, jQuery or other client toolkits. If this is of any interest to you, please send me your phone number and resume and I'll call you back. Regards, Michael Zedeler. Tel. +45 70 25 19 99. LeasingB?rsen.dk ApS Njalsgade 106, 2. 2300 K?benhavn S From zzbbyy w gmail.com Fri Jan 21 04:32:06 2011 From: zzbbyy w gmail.com (Zbigniew Lukasiak) Date: Fri, 21 Jan 2011 13:32:06 +0100 Subject: [Warszawa-pm] Spotkanie styczniowe Message-ID: Ankieta jest na: http://doodle.com/hgib7fab3ttd39p4 -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/ From wb w sao.pl Fri Jan 21 09:41:41 2011 From: wb w sao.pl (Waldemar Biernacki) Date: Fri, 21 Jan 2011 18:41:41 +0100 Subject: [Warszawa-pm] OTRS Message-ID: <201101211841.41541.wb@sao.pl> Do wszystkich chłopców i dziewczynek! Czy ktoś z Was miał styczność z OTRS? http://otrs.org/ Jeśli tak to miałbym pytania... pozdrawiam wb. From zzbbyy w gmail.com Sat Jan 22 06:58:28 2011 From: zzbbyy w gmail.com (Zbigniew Lukasiak) Date: Sat, 22 Jan 2011 15:58:28 +0100 Subject: [Warszawa-pm] =?utf-8?q?Spotkanie_styczniowe_-_Zam=C3=B3wi=C5=82e?= =?utf-8?q?m_stolik_w_Dekancie_na_poniedzia=C5=82ek_na_19?= Message-ID: Wyszło, że poniedziałek i wtorek najbardziej wszystkim pasują - więc nie było już czasu na dłuzsze ustalenia. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/ From stas w datos.pl Mon Jan 24 06:45:45 2011 From: stas w datos.pl (Stanislaw Romanski) Date: Mon, 24 Jan 2011 15:45:45 +0100 Subject: [Warszawa-pm] =?iso-8859-2?q?Spotkanie_styczniowe_-_Zam=F3wi=B3em?= =?iso-8859-2?q?_stolik_w_Dekancie_na_poniedzia=B3ek_na_19?= References: Message-ID: <86E0882F79FD4D4B8099C09D6AF5DF9E@datos57604fe5b> Cześć, Potwierdzam - będę dziś. Stanisław ----- Original Message ----- From: "Zbigniew Lukasiak" To: "warszawa-pm" Sent: Saturday, January 22, 2011 3:58 PM Subject: [Warszawa-pm] Spotkanie styczniowe - Zamówiłem stolik w Dekancie na poniedziałek na 19 Wyszło, że poniedziałek i wtorek najbardziej wszystkim pasują - więc nie było już czasu na dłuzsze ustalenia. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/ _______________________________________________ Warszawa-pm mailing list Warszawa-pm w pm.org http://mail.pm.org/mailman/listinfo/warszawa-pm From zzbbyy w gmail.com Tue Jan 25 00:20:29 2011 From: zzbbyy w gmail.com (Zbigniew Lukasiak) Date: Tue, 25 Jan 2011 09:20:29 +0100 Subject: [Warszawa-pm] IRC Message-ID: Witam, Na wczorajszym spotkaniu wyszło, że nie wszyscy jeszcze wiedzą o naszym kanale ircowym: #perl.pl na irc.perl.org. Poza tym trzeba się zastanowić co można by zaproponować na spotkanie LUGu - ja myślałem, że może Dependency Injection i zaprosić również programistów innych języków, żeby pokazali jak oni to robią. -- Zbigniew Lukasiak http://brudnopis.blogspot.com/ http://perlalchemy.blogspot.com/