Hackowanie Liferay

[Bartek Zdanowski]

Nowy wątek

2012/2/16 Tomek Lipski <tomek....@gmail.com>

> > Aplikacje jednak zrobili, więc "da się" :)
>
> Mowa m.in. o mnie.
> Żeby dostać niektóre ficzery, to strasznie trzeba hackować. Ja bym nie
> chciał strony confitury na Liferayu. Sry.

Bartku,

Trudno mi tutaj osądzać przyczyny związane z koniecznością hackowania,
ale warto w cichości ducha zrobić rachunek sumienia - czy na pewno
było to zrobione zgodnie z tym jak producent zaleca?

Klient zażyczył sobie własny form rejestracji. Mamy trochę custom fieldów. Zadanie wymagało sprawdzania siły hasła i prawidłowości screenname (nick) przez ajaxa, zanim zostanie niciśnięty przyciśk submit.
Jak byś poprosił Liferaya o sprawdzenie czy hasło spełnia politykę wyklikaną w ustawieniach oraz czy pasuje mu screenname (można ustawić blacklistę)?

Liferay 6.0.6

--
Pozdrawiam,
Bartek Zdanowski

Bloguję http://blog.bartekzdanowski.pl i twittuję http://twitter.com/bartekzdanowski
Confitura 2012 - największa bezpłatna konferencja programistyczna - http://confitura.pl
KO Warsjawa 2012 - warszawskie jesienne warsztaty javowe - http://warsjawa.pl

[sebastian.konkol]

Bartku,
w takim razie nie hackuj - napisz formatkę rejestracji w Vaadinie
(portlet) a logikę zintegruj za pomocą ServiceBuilderów lub po prostu
użyj serwisów do tworzenia użytkownika. Naprawdę nie widzę tu w ogóle
pola do "hackowania" :-).

On 16 Lut, 16:38, Bartek Zdanowski <bartek.zdanow...@gmail.com> wrote:
> Nowy wątek
>

> 2012/2/16 Tomek Lipski <tomek.lip...@gmail.com>

>
>
>
> > > > Aplikacje jednak zrobili, więc "da się" :)
>
> > > Mowa m.in. o mnie.
> > > Żeby dostać niektóre ficzery, to strasznie trzeba hackować. Ja bym nie
> > > chciał strony confitury na Liferayu. Sry.
>
> > Bartku,
>
> > Trudno mi tutaj osądzać przyczyny związane z koniecznością hackowania,
> > ale warto w cichości ducha zrobić rachunek sumienia - czy na pewno
> > było to zrobione zgodnie z tym jak producent zaleca?
>
> Klient zażyczył sobie własny form rejestracji. Mamy trochę custom fieldów.
> Zadanie wymagało sprawdzania siły hasła i prawidłowości screenname (nick)
> przez ajaxa, zanim zostanie niciśnięty przyciśk submit.
> Jak byś poprosił Liferaya o sprawdzenie czy hasło spełnia politykę
> wyklikaną w ustawieniach oraz czy pasuje mu screenname (można ustawić
> blacklistę)?
>
> Liferay 6.0.6
>
> --
> Pozdrawiam,
> Bartek Zdanowski
>

> Blogujęhttp://blog.bartekzdanowski.pli twittujęhttp://twitter.com/bartekzdanowski
> Confitura 2012 - największa bezpłatna konferencja programistyczna -http://confitura.pl

[Tomek Lipski]

> Klient zażyczył sobie własny form rejestracji. Mamy trochę custom fieldów.
> Zadanie wymagało sprawdzania siły hasła i prawidłowości screenname (nick)
> przez ajaxa, zanim zostanie niciśnięty przyciśk submit.

Jeśli chodzi o custom fieldy - można zrobić hook do mechanizmu to
obsługującego (create_account.jsp itd.)
Oczywiście custom fields - za pomocą Expando (Custom Fields w Control
Panel). Nikt też nie broni dołożyć akcji AJAXowej, która sprawdzi
hasło.

Można też, tak jak radzi Sebastian - napisać formatkę w Vaadinie,
który zawoła API/usługę :)

> Jak byś poprosił Liferaya o sprawdzenie czy hasło spełnia politykę
> wyklikaną w ustawieniach oraz czy pasuje mu screenname (można ustawić
> blacklistę)?

Hasło - wołamy np. PwdToolkitUtil.validate(companyId, userId,
password1, password2, passwordPolicy);

Screen name - do walidacji jest API, tylko niestety niekompletne:

ScreenNameValidator screenNameValidator =
ScreenNameValidatorFactory.getInstance();

ale w UserLocalServiceImpl.validateScreenName jest dodatkowa logika
walidacyjna (min. wspomniana black lista) a ta metoda i
wołające ją walidujące chyba wszystkie są protected, więc nie ma
publicznego dostępu do metod walidujących (przyczyn może być kilka).

Więc tutaj faktycznie nie jest już w 100% gładko - ale też bez paniki.

Jedno podejście, które w tej chwili przychodzi mi do głowy, to (jest
to dość nieźle opisane w Liferay in Action) wystawienie swojego
Service,
który rozszerzy pod spodem UserLocalServiceImpl (ale sam nie będzie
implementacją UserService, bo nie jest to konieczne) i
upubliczni metodę validującą użytkownika albo samo screen name i
hasło.

Nie jest to idealne rozwiązanie (korzystamy jednak pod spodem z metody
protected), ale ta nie-idealność jest wtedy odseparowana od reszty
aplikacji
oraz samego portalu.

t

[Jacek Laskowski]

2012/2/17 Tomek Lipski <tomek....@gmail.com>:

> Można też, tak jak radzi Sebastian - napisać formatkę w Vaadinie,
> który zawoła API/usługę :)

I teraz jeszcze się okaże, że "sczardżowali" klienta nadmiarowo :)

Dobrze, że Bartek rozpoczął ten wątek, bo pokazuje, że wiedza siedzi w
głowach u różnych ludzi, a jedynym problemem jest dobranie się w
odpowiednie zespoły. Widać, że WJUG spełnia swoją rolę. Brakuje mi
jeszcze w naszej branży zwyczaju zestawiania się w zespoły pod projekt
- ktoś kiedyś o tym wspominał, że przypominałoby to takie luźne
formacje jazzowe, które schodzą się na jeden, dwa występy, może płytę
i ciao. Temat na inny wątek.

Jacek

--
Jacek Laskowski
Java EE, functional languages and IBM WebSphere - http://blog.japila.pl
Warszawa JUG conference = Confitura (formerly Javarsovia) :: http://confitura.pl
"Hoping to save time by spending it" by David Blevins (Apache OpenEJB)

[Bartek Zdanowski]

Takich tematow jest mnostwo i wlasnie w doswiadczeniu tkwi sila JUGa.
Tylko w sumie ludzie malo pytaja. Pewnie kazdy sie wstydzi zblaznic
pytaniem, na ktore powinno sie znac odpowiedz.
A moze powinien byc anonimowy formularz do postowania na WJUG
wstydliwych pytan? :)

> --
> Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
> Więcej informacji na stronie
> http://groups.google.com/group/warszawa-jug?hl=pl
> Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
> Oferty pracy dozwolone zgodnie z zasadami na
> http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie
>

--
Sent from my mobile device

[jacek szczukocki]

Mi ten pomysł się podoba, a tak przy okazji ostatnio testowałem narzędzia dystrybucji BackTrack na aplikacjach javowych...

Może ktoś byłby zainteresowany pentestami pod javą?

[Tomek Lipski]

On Feb 17, 11:54 am, Bartek Zdanowski <bartek.zdanow...@gmail.com>
wrote:

> Takich tematow jest mnostwo i wlasnie w doswiadczeniu tkwi sila JUGa.
> Tylko w sumie ludzie malo pytaja. Pewnie kazdy sie wstydzi zblaznic
> pytaniem, na ktore powinno sie znac odpowiedz.

To niedobrze, bo dobre pytanie jest czasami nawet ciekawsze od
odpowiedzi. I nie ma czego się wstydzić - tu raczej przy udzielaniu
odpowiedzi trzeba pilnować żeby się nie zbłaźnić.

> A moze powinien byc anonimowy formularz do postowania na WJUG
> wstydliwych pytan? :)

wiem, że przynudzam, ale w Liferayu jest od tego Web Forms
Portlet ;-)
np. użyty tutaj jeśli intuicja mnie nie myli: https://vaadin.com/contact
ale to w sumie wątek dla confitura.pl

t

[Bartek Zdanowski]

2012/2/17 Tomek Lipski <tomek....@gmail.com>

> Klient zażyczył sobie własny form rejestracji. Mamy trochę custom fieldów.
> Zadanie wymagało sprawdzania siły hasła i prawidłowości screenname (nick)
> przez ajaxa, zanim zostanie niciśnięty przyciśk submit.

Jeśli chodzi o custom fieldy - można zrobić hook do mechanizmu to
obsługującego (create_account.jsp itd.)
Oczywiście custom fields - za pomocą Expando (Custom Fields w Control
Panel). Nikt też nie broni dołożyć akcji AJAXowej, która sprawdzi
hasło.

Można też, tak jak radzi Sebastian - napisać formatkę w Vaadinie,
który zawoła API/usługę :)

> Jak byś poprosił Liferaya o sprawdzenie czy hasło spełnia politykę
> wyklikaną w ustawieniach oraz czy pasuje mu screenname (można ustawić
> blacklistę)?

Hasło - wołamy np. PwdToolkitUtil.validate(companyId, userId,
password1, password2, passwordPolicy);

Z mojego kodu mam dostęp do
 portal-service.jar gdzie leżą interfejsy usług Liferaya
a do
portal-impl.jar gdzie leży implementacja, w tym PwdToolkitUtil
nie mam.

Screen name - do walidacji jest API, tylko niestety niekompletne:

ScreenNameValidator screenNameValidator =
ScreenNameValidatorFactory.getInstance();

ale w UserLocalServiceImpl.validateScreenName jest dodatkowa logika
walidacyjna (min. wspomniana black lista) a ta metoda i
wołające ją walidujące chyba wszystkie są protected, więc nie ma
publicznego dostępu do metod walidujących (przyczyn może być kilka).

Więc tutaj faktycznie nie jest już w 100% gładko - ale też bez paniki.

Jedno podejście, które w tej chwili przychodzi mi do głowy, to (jest
to dość nieźle opisane w Liferay in Action) wystawienie swojego
Service,
który rozszerzy pod spodem UserLocalServiceImpl (ale sam nie będzie
implementacją UserService, bo nie jest to konieczne) i
upubliczni metodę validującą użytkownika albo samo screen name i
hasło.

Sprawdzę.
 

Nie jest to idealne rozwiązanie (korzystamy jednak pod spodem z metody
protected), ale ta nie-idealność jest wtedy odseparowana od reszty
aplikacji
oraz samego portalu.

t

--
Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
Więcej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
Oferty pracy dozwolone zgodnie z zasadami na http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie

[Jacek Laskowski]

2012/2/17 Tomek Lipski <tomek....@gmail.com>:

> To niedobrze, bo dobre pytanie jest czasami nawet ciekawsze od
> odpowiedzi. I nie ma czego się wstydzić - tu raczej przy udzielaniu
> odpowiedzi trzeba pilnować żeby się nie zbłaźnić.

Ciekawe. Ogólne postrzeganie (i pewnie moje takie było) jest takie, że
to pytający jest na straconej pozycji, ale właśnie otworzyłeś mi oczy!
Obaj mają takie same szanse i tutaj znajduję odpowiedź, dlaczego tak
wiele osób po prostu przysłuchuje się dyskusjom (nasłuchuje) - tutaj
nie mamy możliwości się zbłaźnić, a jakimś cudem boimy się tego
panicznie. Bez pytań nie ma rozwoju, a z nimi możemy się zbłaźnić.
Pytam zatem: "No i co z tego?!"

Dzięki Tomku za pouczające zdanko! Weekend zapowiada się radośnie :)

[Jacek Laskowski]

2012/2/17 Bartek Zdanowski <bartek.z...@gmail.com>:

> Takich tematow jest mnostwo i wlasnie w doswiadczeniu tkwi sila JUGa.
> Tylko w sumie ludzie malo pytaja. Pewnie kazdy sie wstydzi zblaznic
> pytaniem, na ktore powinno sie znac odpowiedz.
> A moze powinien byc anonimowy formularz do postowania na WJUG
> wstydliwych pytan? :)

Eeee, nie idźmy w tym kierunku. Coś mi mówi, że wypowiedź bez autora
ma jakąś mniejszą wartość dla mnie.

Mam wrażenie, że kiedy człowiek błaźni się, jest w tym błogim stanie,
w którym idzie się od kogoś czegoś nauczyć. W końcu do zbłaźnienia
potrzebna jest strona, która sprawia, że jest to w ogóle możliwe, a
skoro ona wie więcej, jest szansa, że i my będziemy. Ceną jest
potencjalne zbłaźnienie się, ale sądzę, że warto ją zapłacić. Zresztą,
nie powinno ubywać nam od tego poziomu naszego wewnętrznego ego.

[Tomek Lipski]

On 17 Lut, 14:51, Bartek Zdanowski <bartek.zdanow...@gmail.com> wrote:

> > Hasło - wołamy np. PwdToolkitUtil.validate(companyId, userId,
> > password1, password2, passwordPolicy);
>
> Z mojego kodu mam dostęp do
>  portal-service.jar gdzie leżą interfejsy usług Liferaya
> a do
> portal-impl.jar gdzie leży implementacja, w tym PwdToolkitUtil
> nie mam.

Fakt, nie zauważyłem, że powyższe klasy są w portal-impl.jar.

t

[Bartek Zdanowski]

2012/2/17 Tomek Lipski <tomek....@gmail.com>

Tak. Dlatego hackowałem. Ale spróbuję zrobić własny service. Czy wtedy mam dostęp?

 

t

--
Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
Więcej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
Oferty pracy dozwolone zgodnie z zasadami na http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie

[Tomek Lipski]

> > Fakt, nie zauważyłem, że powyższe klasy są w portal-impl.jar.
>
> Tak. Dlatego hackowałem. Ale spróbuję zrobić własny service. Czy wtedy mam
> dostęp?

Dostęp do klas z portal-impl.jar mają jedynie pluginy Ext z tego co
się orientuję. Ponadto, według ext plugin guide, robienie usług jako
Ext jest deprecated - chociaż pewnie i tak lepsze i bardziej
przenaszalne niż grzebanie w kodach "na żywca".

Co można zrobić (chociaż mi się to nie podoba, ale powiedzmy, że to
"mniejsze zło"), to przychodzi mi do głowy teraz tylko coś takiego:
1. Stworzyć ext plugin
2. Nadpisać UserLocalServiceImpl swoją implementacją, która będzie z
tego UserLocalServiceImpl dziedziczyć - i ta interpretacja może na
przykład nadpisać metodę updateUser, aby sprawdzała specjalne id np. <
0 i jeśli to id jest - to tylko walidowała.

Można to potraktować jako custom business logic przy odrobinie dobrej
woli. Ale tak - przyznaję bez bicia, trochę podpada to pod hackowanie,
co prawda pod kontrolą i jako plugin, ale jednak dość "advanced".
Chociaż i tak jest to przynajmniej jakaś furtka pozostawiona przez
oprogramowanie, co w sumie rzadko się zdarza a jednak niektóre
frameworki/biblioteki lubią ukrywać swoje klasy (np. Apache Felix).

t

[Bartek Zdanowski]

Troche mnie cieszy to co piszesz,bo (teraz bez wstydu-apropos dyskusji
o pytaniach), moge napisac, ze zrobilem to tak, ze mam specjalnego
usera "technicznego", ktoremu ustawiam nicka albo haslo i sprawdzam
reakcje uslug liferaya. Potem przywracam specjalny nick i haslo a
wynik walidacji wysylam ajaxem do formularza. W ten sposob zaprzegam
ukryte i wewnetrzne mechanizmy liferayowe do moich celow. Przynajmniej
ani nie injectuje ani nie "reflectuje" kodu uslug liferay.
Jest hookowanie serwisow liferay (LR), gdy podkladasz mu swoja impl.
Korzystamy z tego aby dane usera w LR zapisac do zewn. systemu, gdy sa
zmieniane z panelu adm LR.
Moze tam upchne jakas metode gadajaca z bebchami,ale bede musial
rzutowac na swoja klase, bo dostaje impl interfejsu UserLocalService
kiedy prosze LR o niego.

> --
> Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
> Więcej informacji na stronie
> http://groups.google.com/group/warszawa-jug?hl=pl
> Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
> Oferty pracy dozwolone zgodnie z zasadami na
> http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie
>

--

Sent from my mobile device

Pozdrawiam,

[Tomek Lipski]

On Feb 17, 10:16 pm, Bartek Zdanowski <bartek.zdanow...@gmail.com>
wrote:

> Troche mnie cieszy to co piszesz,bo (teraz bez wstydu-apropos dyskusji
> o pytaniach), moge napisac, ze zrobilem to tak, ze mam specjalnego
> usera "technicznego", ktoremu ustawiam nicka albo haslo i sprawdzam
> reakcje uslug liferaya. Potem przywracam specjalny nick i haslo a
> wynik walidacji wysylam ajaxem do formularza. W ten sposob zaprzegam
> ukryte i wewnetrzne mechanizmy liferayowe do moich celow. Przynajmniej
> ani nie injectuje ani nie "reflectuje" kodu uslug liferay.
> Jest hookowanie serwisow liferay (LR), gdy podkladasz mu swoja impl.
> Korzystamy z tego aby dane usera w LR zapisac do zewn. systemu, gdy sa
> zmieniane z panelu adm LR.
> Moze tam upchne jakas metode gadajaca z bebchami,ale bede musial
> rzutowac na swoja klase, bo dostaje impl interfejsu UserLocalService
> kiedy prosze LR o niego.

Tak, tym razem faktycznie, z tą metodą API (validate) sprawa okazała
się być bardziej skomplikowana. Jednocześnie należy pamiętać,
że Liferay wystawia bardzo dużo metod w API, którymi zazwyczaj
spokojnie można zrealizować potrzebną funkcjonalność.

Ale jak widać - jak nawet musimy zrobić coś, co nie przyszło autorom
Liferaya do głowy, to i tak Liferay pozwala nam mieć to pod względną
kontrolą.

t

[Bartek Zdanowski]

2012/2/18 Tomek Lipski <tomek....@gmail.com>

Poczytałem o hookach, ale napisane jest tam, że kod zostanie załadowany przez class loadera mojego WARa.
Da się coś wstrzyknąć do class loadera Liferaya?

t

--
Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
Więcej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
Oferty pracy dozwolone zgodnie z zasadami na http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie

--

[Tomek Lipski]

On Feb 20, 10:06 am, Bartek Zdanowski <bartek.zdanow...@gmail.com>
wrote:

> > Ale jak widać - jak nawet musimy zrobić coś, co nie przyszło autorom
> > Liferaya do głowy, to i tak Liferay pozwala nam mieć to pod względną
> > kontrolą.
>
> Poczytałem o hookach, ale napisane jest tam, że kod zostanie załadowany
> przez class loadera mojego WARa.
> Da się coś wstrzyknąć do class loadera Liferaya?

Do tego służy właśnie mechanizm Ext z tego co się orientuję.

t

[Piotr Pietrzak]

http://www.liferay.com/community/wiki/-/wiki/Main/Portal+Hook+Plugins#section-Portal+Hook+Plugins-Overriding+Services
"Starting with Liferay 6.0 and 5.2 EE SP4, you can override services
using hooks as opposed to doing so in the EXT."

Piotrek

[Bartek Zdanowski]

2012/2/20 Piotr Pietrzak <pi...@macintosh.pl>

W doc
http://www.liferay.com/documentation/liferay-portal/6.0/development/-/ai/overriding-a-portal-service
jest napisane ze hook jest ladowany przez classloadera mojego WAR. Dobrze rozumiem?

[Piotr Pietrzak]

Wiadomość napisana przez Bartek Zdanowski w dniu 20 lut 2012, o godz. 16:20:

2012/2/20 Piotr Pietrzak <pi...@macintosh.pl>

On 20 Lut, 10:31, Tomek Lipski <tomek.lip...@gmail.com> wrote:
> On Feb 20, 10:06 am, Bartek Zdanowski <bartek.zdanow...@gmail.com>
> wrote:
>
> > > Ale jak widać - jak nawet musimy zrobić coś, co nie przyszło autorom
> > > Liferaya do głowy, to i tak Liferay pozwala nam mieć to pod względną
> > > kontrolą.
>
> > Poczytałem o hookach, ale napisane jest tam, że kod zostanie załadowany
> > przez class loadera mojego WARa.
> > Da się coś wstrzyknąć do class loadera Liferaya?
>
> Do tego służy właśnie mechanizm Ext z tego co się orientuję.

http://www.liferay.com/community/wiki/-/wiki/Main/Portal+Hook+Plugins#section-Portal+Hook+Plugins-Overriding+Services
"Starting with Liferay 6.0 and 5.2 EE SP4, you can override services
using hooks as opposed to doing so in the EXT."

W doc
http://www.liferay.com/documentation/liferay-portal/6.0/development/-/ai/overriding-a-portal-service
jest napisane ze hook jest ladowany przez classloadera mojego WAR. Dobrze rozumiem?

Ja to pakuję zawsze w oddzielne wary, bo lubię mieć jak w linuxie - dużo małych prostych narzędzi, które robią dokładnie jedną rzecz. Pewnie można to sobie dopiąć do aplikacji, ale nigdy tego nie praktykowałem i nie wiem jaki będzie efekt/ czy pojawią się problemy.

Mechanizm ten według legendy został zaprojektowany przez gości z SUN, którzy to zforkowali Liferaya, dodali na licencji GPL możliwość wytwarzania hooków, a następnie zaczęli dostarczać własnościowe hooki zwiększające możliwości Liferaya, których już nie musieli wypuszczać na licencji GPL. 

Po wycofaniu się SUN(a raczej Oracle) z Liferaya mechanizm pojawił się w repozytoriach głównych za sprawą głównego developera Liferaya.

Nie będę się wymądrzał na temat classloadera, bo nie miałem z nim zbyt wiele problemów do tej pory, więc się nie poznaliśmy. Liferay używa własnego mechanizmu ładowania klas od wersji 4 i wyobrażam sobie, że to proxy jest robione z zastosowaniem właśnie tego kroku.

Pozdrawiam,

Piotrek

--
Pozdrawiam,
Bartek Zdanowski

Bloguję http://blog.bartekzdanowski.pl i twittuję http://twitter.com/bartekzdanowski
Confitura 2012 - największa bezpłatna konferencja programistyczna - http://confitura.pl
KO Warsjawa 2012 - warszawskie jesienne warsztaty javowe - http://warsjawa.pl

[sebastian.konkol]

Panowie,
nie przekombinowujecie troszkę? Do expando jest chyba
ExpandoLocalServiceUtil gdzie po nazwie można się z portletu dostać do
zmiennych.

Pozdrawiam
Sebastian Konkol

[Piotr Pietrzak]

On 20 Lut, 21:55, "sebastian.konkol" <sebastian.kon...@gmail.com>
wrote:

> Panowie,
> nie przekombinowujecie troszkę? Do expando jest chyba
> ExpandoLocalServiceUtil gdzie po nazwie można się z portletu dostać do
> zmiennych.

Tytuł wątku sugeruje, że chodzi o hackowanie a nie o racjonalne
spełnienie wymagań biznesowych klienta. Tak się miło dryfowało w
kierunku nadpisywania serwisów a tu kolega tak brutalnie na ziemię
sprowadza:) Faktycznie - racjonalnie podchodząc do sprawy, to
modyfikowanie podstawowej funkcjonalności powinno automatycznie
zapalać czerwoną lampkę z napisem: "coś jest nie tak z analizą wymagań/
architekturą rozwiązania".

Pozdrawiam,
Piotr Pietrzak

[Bartek Zdanowski]

No ale form rejestracji z wlasnymi polami i sprawdzanie sily hasla i
dostepnosci nicka przez ajax jest jak najbardziej biznesowo
uzasadniona funkcjonalnoscia, prawda?
Jak masz kolek zamiast miotly i masz latac na tym, to tylko hackowanie
pozostaje. A gdybym napisal "gimnastyka" zamiast hack, to byloby co
innego?

> --
> Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
> Więcej informacji na stronie
> http://groups.google.com/group/warszawa-jug?hl=pl
> Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
> Oferty pracy dozwolone zgodnie z zasadami na
> http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie
>

--

Sent from my mobile device

Pozdrawiam,

[Jacek Laskowski]

2012/2/21 Bartek Zdanowski <bartek.z...@gmail.com>:

> Jak masz kolek zamiast miotly i masz latac na tym, to tylko hackowanie
> pozostaje.

A może warto poszukać miotły, albo nawet zarzucić temat latania? Jak
to szło: "Jak się ma młotek, to...kurcze, nie pamiętam :(

Jacek

--
Jacek Laskowski
Java EE, functional languages and IBM WebSphere - http://blog.japila.pl

"Never discourage anyone who continually makes progress, no matter how
slow." Plato

[sebastian.konkol]

Bartku,
jedno to kwestia miotły/odkurzacza/kołka a druga to kwestia zapędzenia
się w złym kierunku. Moim zdaniem jesteś w stanie w 100% ukończyć
swoją pracę pisząc banalny portlet (znowu namawiam na Vaadina bo
szybko się w tym klepie UI), który wykona opisane zadanie biznesowe
tylko w oparciu o *LocalServiceUtil-e. Oczywiście możemy w tym celu
napisać własny serwis za pomocą ServiceBuildera ale to jest strasznie
przekombinowane rozwiązanie w momencie gdy Liferay dostarcza wszelkie
niezbędne klocki (jeżeli któregoś według Ciebie nie ma, to proszę
powiedz którego - może faktycznie się mylę).

> > Zachęcamy do odwiedzenia naszej strony domowejhttp://warszawa.jug.pl

> > Oferty pracy dozwolone zgodnie z zasadami na
> >http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie
>
> --
> Sent from my mobile device
>
> Pozdrawiam,
> Bartek Zdanowski
>

> Blogujęhttp://blog.bartekzdanowski.pli twittujęhttp://twitter.com/bartekzdanowski
> Confitura 2012 - największa bezpłatna konferencja programistyczna -http://confitura.pl

[Bartek Zdanowski]

2012/2/21 sebastian.konkol <sebastia...@gmail.com>

Bartku,
jedno to kwestia miotły/odkurzacza/kołka a druga to kwestia zapędzenia
się w złym kierunku. Moim zdaniem jesteś w stanie w 100% ukończyć
swoją pracę pisząc banalny portlet (znowu namawiam na Vaadina bo
szybko się w tym klepie UI), który wykona opisane zadanie biznesowe
tylko w oparciu o *LocalServiceUtil-e. Oczywiście możemy w tym celu
napisać własny serwis za pomocą ServiceBuildera ale to jest strasznie
przekombinowane rozwiązanie w momencie gdy Liferay dostarcza wszelkie
niezbędne klocki (jeżeli któregoś według Ciebie nie ma, to proszę
powiedz którego - może faktycznie się mylę).

Napisz linijkę do sprawdzenia czy hasło
String password = "jkfsjdx75djxcjkc";
spełnia politykę haseł ustawioną w panelu adm.

Drugie "zadanie" :) to jak sprawidzić czy nick
String screenName = "bartek";
jest wolny

Wystarczy mi prosty wynik walidacji, bo mam kontroler (myśmy się zintegrowali z grailsami), który jest przez ajaxa pytany o hasło a inna metoda - o nicka.
Jak podasz mi przykładowy kod, to sobie go wkleję w mój kontroler.

Czyli reasumując:
* mam formularz
* chcę *bez* przeładowywania strony, ajaxem sprawdzić czy hasło jest silne oraz nick jest wolny - zupełnie normalna i dzisiejsza funkcjonalność'

Bedę wdzięczny za eleganckie rozwiązanie, bo wiem, że moje jest hakierskie
 

Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl

Oferty pracy dozwolone zgodnie z zasadami na http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie

--
Pozdrawiam,
Bartek Zdanowski

Bloguję http://blog.bartekzdanowski.pl i twittuję http://twitter.com/bartekzdanowski
Confitura 2012 - największa bezpłatna konferencja programistyczna - http://confitura.pl

[Piotr Pietrzak]

Wiadomość napisana przez Bartek Zdanowski w dniu 21 lut 2012, o godz. 07:41:

No ale form rejestracji z wlasnymi polami i sprawdzanie sily hasla i
dostepnosci nicka przez ajax jest jak najbardziej biznesowo
uzasadniona funkcjonalnoscia, prawda?

Nieprawda:) 

Trochę mnie dziwi, że ktoś próbuje zarządzać użytkownikami w portalu, bo narzędzia tam występujące są mocno prymitywne. Sam portal posiada integrację z AD, LDAP + CAS ... Moim zdaniem jest to zachęta do tego, aby faktycznie użytkowników trzymać w prawdziwym systemie IDM a z liferayem się tylko integrować. W przypadku takiego rozwiązania masz dużo prostszą architekturę a do tego za chwilę i tak będziesz potrzebował SSO i tak, bo w dużej organizacji portal nie istnieje w próżni. W naszym wdrożeniu tożsamością zarządzamy tak jak robiliśmy to zawsze a portal podpięliśmy do naszej bazy użytkowników. Autoryzacja działa po CAS (takie SSO, które łatwo się zapina i jest nam potrzebne do innych aplikacji). 

Zarządzanie użytkownikami na własną rękę i to jeszcze przy użyciu standardowego formularza wbudowanego w portal brzmi jak źle zrobiona analiza. Dobrze zrobione zarządzanie tożsamością to podstawa udanego wdrożenia portalu - bez tego problemy będą się nawarstwiać i czeka Cię migracja na prawdziwe rozwiązania IDM (czyli przenoszenie użytkowników z bazy liferay do powiedzmy AD, czy LDAP, oraz zapięcie SSO i zbudowanie własnych mechanizmów zarządzania uprawnieniami). Po co spiętrzać górkę do przeniesienia? Może lepiej od razu zapiąć się do istniejącego LDAP, AD, czy czegośtam i nie marnować czasu/kasy klienta? A formularz do tworzenia użytkowników czy będzie w ajax z grails, vaadin, gwt, czy php + delphi to wszystko jedno.

Dla mnie zarządzanie użytkownikami to najbardziej złożona część wdrożenia portalu z natury rzeczy. Samo uruchomienie, konfiguracja, optymalizacje i inne problemy techniczne w porównaniu z rozwiązaniem problemów fundamentalnych dużej organizacji (takich jak zarządzanie użytkownikami/uprawnieniami)  to pestka. Złożoność widać również po cenach produktów - często portal jest tańszy od systemu IDM (tak wiem - to śmieszny argument).

Oczywiście moje spojrzenie jest bardzo subiektywne. Może zakres i cel projektu jest inny, niż sobie to wyobrażam, więc moje uwagi są bezzasadne.

Jak masz kolek zamiast miotly i masz latac na tym, to tylko hackowanie
pozostaje. A gdybym napisal "gimnastyka" zamiast hack, to byloby co
innego?

To o czym sobie piszemy z tym wątku nijak się nie ma do rozwiązania problemu, tylko jest właśnie hakowaniem Liferaya. Jak się nie może/chce rozwiązać dobrze prawdziwych problemów, to trzeba kombinować jak koń pod górę, ale przypomina to zaklejanie gumą do żucia dziury w burcie tonącego okrętu.

Faktycznie - w liferayu nie ma miotły a dostarczony kołek jest słaby i się połamie jak będziesz na nim siadał - wniosek: do latania służą samoloty - tylko dzieci uważają, że można latać na miotle i kołku. Czemu kołek jest za słaby a miotły nie ma? - chyba dlatego, że nikt tego po prostu nie używa, więc nie ma motywacji do zbudowania dobrego rozwiązania IDM jako części portalu. Swoją drogą to bardzo dobrze, bo zespół Liferaya ma pomysły związane z wymyślaniem koła (vide własny silnik workflow) - aż strach pomyśleć jak by wyglądało IDM doklejone do portalu.

Pozdrawiam,

Piotrek

P.S.

Jeśli przetniesz zbiór deweloperów http://www.jboss.org/gatein i http://www.jboss.org/picketlink/IDM oraz zbiór członków WJUG, to otrzymasz zbiór niepusty - może teraz Bolek włączy się do dyskusji:) 

[Jacek Laskowski]

2012/2/21 Piotr Pietrzak <p10trp...@gmail.com>:

> Oczywiście moje spojrzenie jest bardzo subiektywne. Może zakres i cel
> projektu jest inny, niż sobie to wyobrażam, więc moje uwagi są bezzasadne.

Cześć Piotr,

Nie byłem specjalnie zainteresowany tematem, ale czytałem go na
bieżąco i przyznam szczerze, że aż dziwię się teraz sobie, że sam nie
wpadłem na ten genialny pomysł z wyniesieniem zarządzaniem
użytkownikami poza portal. Tak właśnie było w moich projektach, ale
zwykle pomysłodawcą był ktoś mądrzejszy (może Ty?!)

Wspaniale obsłużyłeś problem. Nie wiem, czy to będzie rozwiązanie
satysfakcjonujące Bartka (inicjatora dyskusji), ale dla mnie jest
wprost wymarzone. Bardzo dziekuję za chęć podzielenia się swoją
opinią, która nota bene zawsze będzie subiektywne, bo jakie inne
mogłoby być, skoro Twoje?! :)

Cudo wątek!

[Jakub Nabrdalik]

On 21.02.2012 11:22, Piotr Pietrzak wrote:
>> No ale form rejestracji z wlasnymi polami i sprawdzanie sily hasla i
>> dostepnosci nicka przez ajax jest jak najbardziej biznesowo
>> uzasadniona funkcjonalnoscia, prawda?
> Nieprawda:)
> Trochę mnie dziwi, że ktoś próbuje zarządzać użytkownikami w portalu, bo
> narzędzia tam występujące są mocno prymitywne. Sam portal posiada
> integrację z AD, LDAP + CAS ... Moim zdaniem jest to zachęta do tego,
> aby faktycznie użytkowników trzymać w prawdziwym systemie IDM a z
> liferayem się tylko integrować. W przypadku takiego rozwiązania masz
> dużo prostszą architekturę a do tego za chwilę i tak będziesz
> potrzebował SSO i tak, bo w dużej organizacji portal nie istnieje w próżni.

Mam wrażenie, że organizacja którą ma na myśli Bartek, nazywa się
"Internet" :). Tam z SSO jest trochę krucho [1].

[1] oczywiście istnieją oauth/openid, szkoda tylko, że nie w świadomości
userów

--
Jakub Nabrdalik
blog.solidcraft.eu

[sebastian.konkol]

Bartku,
Piotr Pietrzak poniżej ma rację - używanie Liferaya do tego celu to
półśrodek, ale jeżeli chcesz sprawdzić jakie są ustawione reguły polis
dla uwierzytelnianiania to robisz to za pomocą serwisu
PasswordPolicyLocalServiceUtil.getDefaultPasswordPolicy(companyId) -
to jest o ile mnie pamięć nie myli bo dawno tego nie oglądałem :-). Co
do sprawdzenia czy User istnieje z zadanym screennamem to pomaga
warunek (UserLocalServiceUtil.getUserByScreenName(userId,
"mój_zajefajny_screen_name")!=null).

Pozdrawiam
Sebastian Konkol

On 21 Lut, 09:37, Bartek Zdanowski <bartek.zdanow...@gmail.com> wrote:
> 2012/2/21 sebastian.konkol <sebastian.kon...@gmail.com>

> > > Confitura 2012 - największa bezpłatna konferencja programistyczna -
> >http://confitura.pl
> > > KO Warsjawa 2012 - warszawskie jesienne warsztaty javowe -
> >http://warsjawa.pl
>

> > --
> > Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
> > Więcej informacji na stronie
> >http://groups.google.com/group/warszawa-jug?hl=pl
> > Zachęcamy do odwiedzenia naszej strony domowejhttp://warszawa.jug.pl
> > Oferty pracy dozwolone zgodnie z zasadami na
> >http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie
>
> --

[Bartek Zdanowski]

2012/2/21 Piotr Pietrzak <p10trp...@gmail.com>

Wiadomość napisana przez Bartek Zdanowski w dniu 21 lut 2012, o godz. 07:41:

No ale form rejestracji z wlasnymi polami i sprawdzanie sily hasla i
dostepnosci nicka przez ajax jest jak najbardziej biznesowo
uzasadniona funkcjonalnoscia, prawda?

Nieprawda:) 

Trochę mnie dziwi, że ktoś próbuje zarządzać użytkownikami w portalu, bo narzędzia tam występujące są mocno prymitywne. Sam portal posiada integrację z AD, LDAP + CAS ... Moim zdaniem jest to zachęta do tego, aby faktycznie użytkowników trzymać w prawdziwym systemie IDM a z liferayem się tylko integrować. W przypadku takiego rozwiązania masz dużo prostszą architekturę a do tego za chwilę i tak będziesz potrzebował SSO i tak, bo w dużej organizacji portal nie istnieje w próżni. W naszym wdrożeniu tożsamością zarządzamy tak jak robiliśmy to zawsze a portal podpięliśmy do naszej bazy użytkowników. Autoryzacja działa po CAS (takie SSO, które łatwo się zapina i jest nam potrzebne do innych aplikacji). 

Zarządzanie użytkownikami na własną rękę i to jeszcze przy użyciu standardowego formularza wbudowanego w portal brzmi jak źle zrobiona analiza. Dobrze zrobione zarządzanie tożsamością to podstawa udanego wdrożenia portalu - bez tego problemy będą się nawarstwiać i czeka Cię migracja na prawdziwe rozwiązania IDM (czyli przenoszenie użytkowników z bazy liferay do powiedzmy AD, czy LDAP, oraz zapięcie SSO i zbudowanie własnych mechanizmów zarządzania uprawnieniami). Po co spiętrzać górkę do przeniesienia? Może lepiej od razu zapiąć się do istniejącego LDAP, AD, czy czegośtam i nie marnować czasu/kasy klienta? A formularz do tworzenia użytkowników czy będzie w ajax z grails, vaadin, gwt, czy php + delphi to wszystko jedno.

Dla mnie zarządzanie użytkownikami to najbardziej złożona część wdrożenia portalu z natury rzeczy. Samo uruchomienie, konfiguracja, optymalizacje i inne problemy techniczne w porównaniu z rozwiązaniem problemów fundamentalnych dużej organizacji (takich jak zarządzanie użytkownikami/uprawnieniami)  to pestka. Złożoność widać również po cenach produktów - często portal jest tańszy od systemu IDM (tak wiem - to śmieszny argument).

Oczywiście moje spojrzenie jest bardzo subiektywne. Może zakres i cel projektu jest inny, niż sobie to wyobrażam, więc moje uwagi są bezzasadne.

Dzięki za propozycje, ale jak Kuba Nabrdalik napisał, mam do czynienia z userami którzy na stronie internetowej się rejestrują.
Klient zażyczył sobie, aby można było zrealizować user story które opisuję od dłuższego czasu różnymi słowami.
Formularz. Ajax. Walidacja screen name i password *przed* postem całego forma. Nic mniej. Nic więcej.
 

[Tomek Banach]

On 2012-02-17 11:54, Bartek Zdanowski wrote:
> Takich tematow jest mnostwo i wlasnie w doswiadczeniu tkwi sila JUGa.
> Tylko w sumie ludzie malo pytaja. Pewnie kazdy sie wstydzi zblaznic
> pytaniem, na ktore powinno sie znac odpowiedz.
> A moze powinien byc anonimowy formularz do postowania na WJUG
> wstydliwych pytan? :)

A czy taki wjug jest dobrym miejscem na takie rozmowy ? Ja osobiście
podchodzę do tej listy jako do miejsca o informacjach warszawsko
społecznościowych a pomocy szukałbym na czymś o większym zasięgu. Bo
przecież samych polskich jugów jest klika.
W sumie smutne że polska grupa usenetowa jest w zasadzie martwa.

Chyba że na zasadzie mniejsza grupa lepiej się zna więc jest większa
motywacja żeby pomóc koledze z okolicy niż anomiomowemu pseudo "skądś tam".

--
Tomek

[Piotr Pietrzak]

On 21 Lut, 12:09, Jakub Nabrdalik <jak...@gmail.com> wrote:
> On 21.02.2012 11:22, Piotr Pietrzak wrote:
>
> >> No ale form rejestracji z wlasnymi polami i sprawdzanie sily hasla i
> >> dostepnosci nicka przez ajax jest jak najbardziej biznesowo
> >> uzasadniona funkcjonalnoscia, prawda?
> > Nieprawda:)
> > Trochę mnie dziwi, że ktoś próbuje zarządzać użytkownikami w portalu, bo
> > narzędzia tam występujące są mocno prymitywne. Sam portal posiada
> > integrację z AD, LDAP + CAS ... Moim zdaniem jest to zachęta do tego,
> > aby faktycznie użytkowników trzymać w prawdziwym systemie IDM a z
> > liferayem się tylko integrować. W przypadku takiego rozwiązania masz
> > dużo prostszą architekturę a do tego za chwilę i tak będziesz
> > potrzebował SSO i tak, bo w dużej organizacji portal nie istnieje w próżni.
>
> Mam wrażenie, że organizacja którą ma na myśli Bartek, nazywa się
> "Internet" :). Tam z SSO jest trochę krucho [1].
>

http://www.zgeek.com/forum/gallery/files/7/6/0/1/it_crowd___the_internet_by_surlana.jpg
W tej organizacji to bym wdrożył LDAP z innego powodu - relacyjna baza
danych używająca expando trudniej się skaluje od LDAPa.

> [1] oczywiście istnieją oauth/openid, szkoda tylko, że nie w świadomości
> userów

Ostatnio popularne są "zaloguj na tweeterze, zaloguj na FB" - nie
tylko na zachodzie, ale również na wschodzie staje się to coraz
bardziej popularne, z naszej działki: https://social.jrebel.com/

Taki portal to projekt z cyklem życia liczonym w latach - facebook
dopiero od września 2009 przestał generować straty i przynosić zyski.
Sieć się zmienia a wraz z nią użytkownicy i ich świadomość. Trochę to
przypomina stwierdzenie "Internet to przejściowa moda" przypisywane
Gatesowi ale to rynek weryfikuje trafność hipotez biznesowych.
Logowanie za pośrednictwem innych serwisów ma jeszcze jedną zaletę -
formy nie staną się systemem typu "qwe collector", bo ktoś jak ma
konto w gmail, to może zależeć mu na tym napisie przed "@" i ładnym
opisie w polu imię, nazwisko...

Pozdrawiam,
Piotrek

[Bartek Zdanowski]

2012/2/21 sebastian.konkol <sebastia...@gmail.com>

Bartku,
Piotr Pietrzak poniżej ma rację - używanie Liferaya do tego celu to
półśrodek, ale jeżeli chcesz sprawdzić jakie są ustawione reguły polis
dla uwierzytelnianiania to robisz to za pomocą serwisu
PasswordPolicyLocalServiceUtil.getDefaultPasswordPolicy(companyId) -
to jest o ile mnie pamięć nie myli bo dawno tego nie oglądałem :-). Co

Sprawdzę jak to się je.
 

do sprawdzenia czy User istnieje z zadanym screennamem to pomaga
warunek (UserLocalServiceUtil.getUserByScreenName(userId,
"mój_zajefajny_screen_name")!=null).

Tak, ale nie da mi to sprawdzenia z blacklistą.
Można jakoś black listę wyssać?

Prawie jesteśmy na miejscu!
 

Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl

Oferty pracy dozwolone zgodnie z zasadami na http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie

--
Pozdrawiam,
Bartek Zdanowski

Bloguję http://blog.bartekzdanowski.pl i twittuję http://twitter.com/bartekzdanowski

[Bartek Zdanowski]

2012/2/21 Tomek Banach <to...@banciur.org>

Tak. Właśnie tak to działa. Dużo życzliwych ludzi, którzy pomagają nie-anonimowym członkom grupy.
Potem dopiero uderzam dalej.
 

--
Tomek

--
Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
Więcej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
Oferty pracy dozwolone zgodnie z zasadami na http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie

[sebastian.konkol]

Samej blacklisty chyba nie da się wyssać - ale createUser w
UserLocalServiceUtil powinien plunąć wyjątkiem gdy próbujesz utworzyć
usera z usernamem blacklistowym (rozumiem, że chodzi o reserved screen
names?).

> > > > > Blogujęhttp://blog.bartekzdanowski.plitwittuję<http://blog.bartekzdanowski.xn--plitwittuj-nnb>

[Bartek Zdanowski]

2012/2/21 sebastian.konkol <sebastia...@gmail.com>

Samej blacklisty chyba nie da się wyssać - ale createUser w
UserLocalServiceUtil powinien plunąć wyjątkiem gdy próbujesz utworzyć
usera z usernamem blacklistowym (rozumiem, że chodzi o reserved screen
names?).

Tak dokładnie. A jak to zaprząc, aby działało sprawdzanie screen name (nick) przez ajaxa?

 

--
Pozdrawiam,
Bartek Zdanowski

Bloguję http://blog.bartekzdanowski.pl i twittuję http://twitter.com/bartekzdanowski

[sebastian.konkol]

Co do haseł to zerknij jeszcze na
PasswordTrackerLocalServiceUtil.isValidPassword a odnośnie tej
nieszczęsnej blacklisty .. chwile szperania i chyba znalazłem:

String adminReservedScreenNames = ParamUtil.getString(request,
"settings--" + PropsKeys.ADMIN_RESERVED_SCREEN_NAMES + "--",
PrefsPropsUtil.getString(company.getCompanyId(),
PropsKeys.ADMIN_RESERVED_SCREEN_NAMES));
String adminReservedEmailAddresses = ParamUtil.getString(request,
"settings--" + PropsKeys.ADMIN_RESERVED_EMAIL_ADDRESSES + "--",
PrefsPropsUtil.getString(company.getCompanyId(),
PropsKeys.ADMIN_RESERVED_EMAIL_ADDRESSES));

ew. tak:

String[] reservedScreenNames = PrefsPropsUtil.getStringArray(
companyId, PropsKeys.ADMIN_RESERVED_SCREEN_NAMES,
StringPool.NEW_LINE, PropsValues.ADMIN_RESERVED_SCREEN_NAMES);
String[] reservedEmailAddresses = PrefsPropsUtil.getStringArray(
companyId, PropsKeys.ADMIN_RESERVED_EMAIL_ADDRESSES,
StringPool.NEW_LINE, PropsValues.ADMIN_RESERVED_EMAIL_ADDRESSES);

Wydaje mi się, że to kończy temat hakierowania Liferaya :-). Mam
nadzieję, że bez większych trudności uda Ci się wprowadzić wymagane ze
strony klienta customizacje :-). Jak będziesz miał jeszcze jakieś
problemy to postuj.

Pozdrawiam
Sebastian Konkol

.

[Bartek Zdanowski]

2012/2/21 sebastian.konkol <sebastia...@gmail.com>

Co do haseł to zerknij jeszcze na
PasswordTrackerLocalServiceUtil.isValidPassword a odnośnie tej
nieszczęsnej blacklisty .. chwile szperania i chyba znalazłem:

String adminReservedScreenNames = ParamUtil.getString(request,
"settings--" + PropsKeys.ADMIN_RESERVED_SCREEN_NAMES + "--",
PrefsPropsUtil.getString(company.getCompanyId(),
PropsKeys.ADMIN_RESERVED_SCREEN_NAMES));
String adminReservedEmailAddresses = ParamUtil.getString(request,
"settings--" + PropsKeys.ADMIN_RESERVED_EMAIL_ADDRESSES + "--",
PrefsPropsUtil.getString(company.getCompanyId(),
PropsKeys.ADMIN_RESERVED_EMAIL_ADDRESSES));

ew. tak:

String[] reservedScreenNames = PrefsPropsUtil.getStringArray(
                       companyId, PropsKeys.ADMIN_RESERVED_SCREEN_NAMES,
                       StringPool.NEW_LINE, PropsValues.ADMIN_RESERVED_SCREEN_NAMES);
String[] reservedEmailAddresses = PrefsPropsUtil.getStringArray(
                       companyId, PropsKeys.ADMIN_RESERVED_EMAIL_ADDRESSES,
                       StringPool.NEW_LINE, PropsValues.ADMIN_RESERVED_EMAIL_ADDRESSES);

Wydaje mi się, że to kończy temat hakierowania Liferaya :-). Mam
nadzieję, że bez większych trudności uda Ci się wprowadzić wymagane ze
strony klienta customizacje :-). Jak będziesz miał jeszcze jakieś
problemy to postuj.

Mega dzięki! Jak obrobię się z bieżącymi taskami, to spróbuję przejść na to co opisałeś.

Wszystkim dziękuję za super dyskusję. Stawiamy portal dla jednego z operatorów GSM i będzie o nim głośno, więc dam linka do *tego* liferaya, jak tylko wejdzie na produkcję. Będziecie mogli stestować czy się spisałem z kolegami z TouK czy nie :)

Dzięki!

--
Pozdrawiam,
Bartek Zdanowski

Bloguję http://blog.bartekzdanowski.pl i twittuję http://twitter.com/bartekzdanowski

[Tomek Lipski]

On Feb 21, 8:11 pm, "sebastian.konkol" <sebastian.kon...@gmail.com>
wrote:
> Co do hase³ to zerknij jeszcze na
> PasswordTrackerLocalServiceUtil.isValidPassword a odno¶nie tej

Hmm, ta metoda niestety nie odpala password policy pod kątem innym niż
obecność takiego hasła poprzednio u użytkownika. Więc przy zakładaniu
nowego konta, będzie ona dosyć krótka.
Pełna logika walidacji hasła użytkownika znowu jest w
UserLocalServiceImpl.validatePassword - ona woła wspomniane (i
dostępne tylko w portal-impl niestety) PwdToolkitUtil.validate, które
woła
odpowiedni toolkit walidujący hasła (są 2 implementacje z tego co
widzę - regexp oraz passwordpolicy).

Chociaż hasło to ja bym generował i wysyłał ludziowi na emaila -
łatwiej, prościej i szybciej. Ale wiadomo - wymaganie biznesowe święte
jest ;-)

> nieszczêsnej blacklisty .. chwile szperania i chyba znalaz³em:

>
> String adminReservedScreenNames = ParamUtil.getString(request,
> "settings--" + PropsKeys.ADMIN_RESERVED_SCREEN_NAMES + "--",
> PrefsPropsUtil.getString(company.getCompanyId(),
> PropsKeys.ADMIN_RESERVED_SCREEN_NAMES));
> String adminReservedEmailAddresses = ParamUtil.getString(request,
> "settings--" + PropsKeys.ADMIN_RESERVED_EMAIL_ADDRESSES + "--",
> PrefsPropsUtil.getString(company.getCompanyId(),
> PropsKeys.ADMIN_RESERVED_EMAIL_ADDRESSES));
>
> ew. tak:
>
> String[] reservedScreenNames = PrefsPropsUtil.getStringArray(
>                         companyId, PropsKeys.ADMIN_RESERVED_SCREEN_NAMES,
>                         StringPool.NEW_LINE, PropsValues.ADMIN_RESERVED_SCREEN_NAMES);
> String[] reservedEmailAddresses = PrefsPropsUtil.getStringArray(
>                         companyId, PropsKeys.ADMIN_RESERVED_EMAIL_ADDRESSES,
>                         StringPool.NEW_LINE, PropsValues.ADMIN_RESERVED_EMAIL_ADDRESSES);
>

Żeby to było takie proste. Walidacja screenname w Liferay
(UserLocalServiceImpl.java) wygląda jak poniżej (patrzę w źródła
6.1.0, ale nie sądzę aby tutaj były duże zmiany). Jest tam więcej
logiki biznesowej niż napisałeś - stąd moja propozycja wołania tej
metody a nie jej powtórnej implementacji. Blacklista to tylko jeden z
checkpointów - mamy jeszcze np. sprawdzanie unikalności pod kątem grup
i friendly url, listę anonymous screen names, itd.

To co proponujesz, to właśnie może sprowadzić Bartka na złą drogę -
wyjdzie nowy Liferay i kod który wkleiłeś będzie do przepisania od
nowa, bo zmieni się np. mechanizm walidowania reserved screen names.
Albo dojdzie nowy mechanizm cache'owania? Albo nowa lista brzydkich
wyrazów w loginach, których nie wolno używać - korzystająca z
globalnego słownika? I co wtedy?

protected void validateScreenName(
long companyId, long userId, String screenName)
throws PortalException, SystemException {

if (Validator.isNull(screenName)) {
throw new UserScreenNameException();
}

ScreenNameValidator screenNameValidator =
ScreenNameValidatorFactory.getInstance();

if (!screenNameValidator.validate(companyId, screenName)) {
throw new UserScreenNameException();
}

if (Validator.isNumber(screenName)) {
if (!PropsValues.USERS_SCREEN_NAME_ALLOW_NUMERIC) {
throw new UserScreenNameException();
}

if (!screenName.equals(String.valueOf(userId))) {
Group group = groupPersistence.fetchByPrimaryKey(
GetterUtil.getLong(screenName));

if (group != null) {
throw new UserScreenNameException();
}
}
}

for (char c : screenName.toCharArray()) {
if ((!Validator.isChar(c)) && (!Validator.isDigit(c)) &&
(c != CharPool.DASH) && (c != CharPool.PERIOD) &&
(c != CharPool.UNDERLINE)) {

throw new UserScreenNameException();
}
}

String[] anonymousNames = PrincipalBean.ANONYMOUS_NAMES;

for (String anonymousName : anonymousNames) {
if (screenName.equalsIgnoreCase(anonymousName)) {
throw new UserScreenNameException();
}
}

User user = userPersistence.fetchByC_SN(companyId, screenName);

if ((user != null) && (user.getUserId() != userId)) {
throw new DuplicateUserScreenNameException();
}

String friendlyURL = StringPool.SLASH + screenName;

Group group = groupPersistence.fetchByC_F(companyId, friendlyURL);

if ((group != null) && (group.getClassPK() != userId)) {
throw new GroupFriendlyURLException(
GroupFriendlyURLException.DUPLICATE);
}

int exceptionType = LayoutImpl.validateFriendlyURL(friendlyURL);

if (exceptionType != -1) {
throw new UserScreenNameException(
new GroupFriendlyURLException(exceptionType));

}

String[] reservedScreenNames = PrefsPropsUtil.getStringArray(
companyId, PropsKeys.ADMIN_RESERVED_SCREEN_NAMES,
StringPool.NEW_LINE, PropsValues.ADMIN_RESERVED_SCREEN_NAMES);

for (String reservedScreenName : reservedScreenNames) {
if (screenName.equalsIgnoreCase(reservedScreenName)) {
throw new ReservedUserScreenNameException();
}
}

t

[Tomek Lipski]

> Mega dzięki! Jak obrobię się z bieżącymi taskami, to spróbuję przejść na to
> co opisałeś.
>
> Wszystkim dziękuję za super dyskusję. Stawiamy portal dla jednego z
> operatorów GSM i będzie o nim głośno, więc dam linka do *tego* liferaya,
> jak tylko wejdzie na produkcję. Będziecie mogli stestować czy się spisałem
> z kolegami z TouK czy nie :)

Nie omieszkamy na pewno :) a może wtedy, bogatszy z doświadczenia z
udanego wdrożenia, już jako Liferay fan, zrobisz od razu z rozpędu
nową stronę Confitury na Liferayu :)))

t

[Bartek Zdanowski]

2012/2/27 Tomek Lipski <tomek....@gmail.com>:

> On Feb 21, 8:11 pm, "sebastian.konkol" <sebastian.kon...@gmail.com>
> wrote:
>> Co do hase³ to zerknij jeszcze na
>> PasswordTrackerLocalServiceUtil.isValidPassword a odno¶nie tej
>
> Hmm, ta metoda niestety nie odpala password policy pod kątem innym niż
> obecność takiego hasła poprzednio u użytkownika. Więc przy zakładaniu
> nowego konta, będzie ona dosyć krótka.
> Pełna logika walidacji hasła użytkownika znowu jest w
> UserLocalServiceImpl.validatePassword - ona woła wspomniane (i
> dostępne tylko w portal-impl niestety) PwdToolkitUtil.validate, które
> woła
> odpowiedni toolkit walidujący hasła (są 2 implementacje z tego co
> widzę - regexp oraz passwordpolicy).

Tak. I nie można sie do tego dobrać z własnego kodu.

>
> Chociaż hasło to ja bym generował i wysyłał ludziowi na emaila -
> łatwiej, prościej i szybciej. Ale wiadomo - wymaganie biznesowe święte
> jest ;-)

Tak. święte

> --
> Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
> Więcej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
> Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl

> Oferty pracy dozwolone zgodnie z zasadami na http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie

--
Pozdrawiam,
Bartek Zdanowski

Bloguję http://blog.bartekzdanowski.pl i twittuję

[Bartek Zdanowski]

2012/2/27 Tomek Lipski <tomek....@gmail.com>:

Nie ma szans :P
W tym wiedzie prym Michał Margiel i jego Jelatyna (+ commiterów).
Zapraszam do rozwijania :D

>
> t

[Tomek Lipski]

On Feb 27, 3:33 pm, Bartek Zdanowski <bartek.zdanow...@gmail.com>
wrote:
> 2012/2/27 Tomek Lipski <tomek.lip...@gmail.com>:

>
> > On Feb 21, 8:11 pm, "sebastian.konkol" <sebastian.kon...@gmail.com>
> > wrote:
> >> Co do hase³ to zerknij jeszcze na
> >> PasswordTrackerLocalServiceUtil.isValidPassword a odno¶nie tej
>
> > Hmm, ta metoda niestety nie odpala password policy pod kątem innym niż
> > obecność takiego hasła poprzednio u użytkownika. Więc przy zakładaniu
> > nowego konta, będzie ona dosyć krótka.
> > Pełna logika walidacji hasła użytkownika znowu jest w
> > UserLocalServiceImpl.validatePassword - ona woła wspomniane (i
> > dostępne tylko w portal-impl niestety) PwdToolkitUtil.validate, które
> > woła
> > odpowiedni toolkit walidujący hasła (są 2 implementacje z tego co
> > widzę - regexp oraz passwordpolicy).
>
> Tak. I nie można sie do tego dobrać z własnego kodu.

Można za to w kontrolowany sposób te metody uwypuklić/udostępnić. Mało
który framework/rozwiązanie IT Ci na to pozwala.
Na pewno będzie to lepsze niż kopiowanie ich kodu. Ah - jedna rzecz -
pisałeś, że masz testowego użytkownika, na którym sprawdzasz
poprawność hasła - czy bierzesz pod uwagę sprawdzanie historii hasła?
Bo może dojść do takiej sytuacji, będącej w teorii dziurką w
bezpieczeństwie:
- user1 proponuje hasło 'haslo123' (dość popularne)
- ustawiasz dla swojego technicznego usera to hasło, jest OK, więc
tworzysz użytkownika
- user2 proponuje hasło 'haslo123' (why not?) - system mu mówi, że
hasło nie jest dobre (po według ustawienia historii, było użyte chwilę
wcześniej)

jeśli user2 jest mądry (i np. spojrzał w kody Liferaya albo w ten
wątek), to właśnie wie, że zgadł hasło innego użytkownika :>. Nie jest
to mocno prawdopodobne, ale pokazuje, że hakowanie nie jest takie
dobre i można się wkopać.

Chociaż też oczywiście wolałbym, żeby po prostu Liferay wystawił api
do walidacji, wtedy by wszyscy byli szczęśliwi. Z innymi metodami jest
tak, jak pisze Sebastian.

t

[Bartek Zdanowski]

2012/2/27 Tomek Lipski <tomek....@gmail.com>

Jest flaga, którą się ustawia czy ma śledzić historię czy nie. Nie ma wymagania biznesowego, aby ta flaga była zaznaczona i ustawiamy ją na false.
 

Chociaż też oczywiście wolałbym, żeby po prostu Liferay wystawił api
do walidacji, wtedy by wszyscy byli szczęśliwi. Z innymi metodami jest
tak, jak pisze Sebastian.

t

--
Wiadomość z grupy Warszawa Java User Group (Warszawa JUG).
Więcej informacji na stronie http://groups.google.com/group/warszawa-jug?hl=pl
Zachęcamy do odwiedzenia naszej strony domowej http://warszawa.jug.pl
Oferty pracy dozwolone zgodnie z zasadami na http://sites.google.com/site/warszawajug/oferty-pracy-na-grupie

[Tomek Lipski]

> > jeśli user2 jest mądry (i np. spojrzał w kody Liferaya albo w ten
> > wątek), to właśnie wie, że zgadł hasło innego użytkownika :>. Nie jest
> > to mocno prawdopodobne, ale pokazuje, że hakowanie nie jest takie
> > dobre i można się wkopać.
>
> Jest flaga, którą się ustawia czy ma śledzić historię czy nie. Nie ma
> wymagania biznesowego, aby ta flaga była zaznaczona i ustawiamy ją na false.
>

Dzisiaj jest na false, po wdrożeniu pójdziesz do innego projektu,
zapomną o wszystkim, zmienią na true (np. podłączą LDAPa z taką
polityką haseł) i potem będzie w gazetach,
tak jak parę lat temu pewien dostawca udostępnił faktury wszystkich
klientów wszystkim zainteresowanym ;-)

ale też to tylko przykład, pokazujący downsides takiego podejścia,
gdzie trochę podchodzimy do problemu dookoła.

t

[Tomek Lipski]

On Feb 27, 3:33 pm, Bartek Zdanowski <bartek.zdanow...@gmail.com>
wrote:

> 2012/2/27 Tomek Lipski <tomek.lip...@gmail.com>:>> Mega dzięki! Jak obrobię się z bieżącymi taskami, to spróbuję przejść na to

> >> co opisałeś.
>
> >> Wszystkim dziękuję za super dyskusję. Stawiamy portal dla jednego z
> >> operatorów GSM i będzie o nim głośno, więc dam linka do *tego* liferaya,
> >> jak tylko wejdzie na produkcję. Będziecie mogli stestować czy się spisałem
> >> z kolegami z TouK czy nie :)
>
> > Nie omieszkamy na pewno :) a może wtedy, bogatszy z doświadczenia z
> > udanego wdrożenia, już jako Liferay fan, zrobisz od razu z rozpędu
> > nową stronę Confitury na Liferayu :)))
>
> Nie ma szans :P
> W tym wiedzie prym Michał Margiel i jego Jelatyna (+ commiterów).
> Zapraszam do rozwijania :D

żeby człowiek miał czas na takie zabawy.. zresztą jeśli dobrze się
bawią przy rozwoju i uczą - to super :)

t

[sebastian.konkol]

Odpowiadając:

> Hmm, ta metoda niestety nie odpala password policy pod kątem innym niż
> obecność takiego hasła poprzednio u użytkownika. Więc przy zakładaniu
> nowego konta, będzie ona dosyć krótka.
> Pełna logika walidacji hasła użytkownika znowu jest w
> UserLocalServiceImpl.validatePassword - ona woła wspomniane (i
> dostępne tylko w portal-impl niestety) PwdToolkitUtil.validate, które
> woła
> odpowiedni toolkit walidujący hasła (są 2 implementacje z tego co
> widzę - regexp oraz passwordpolicy).
>
> Chociaż hasło to ja bym generował i wysyłał ludziowi na emaila -
> łatwiej, prościej i szybciej. Ale wiadomo - wymaganie biznesowe święte
> jest ;-)

Też samemu bym generował hasło, ale skoro takie mają wymagania to
znaczy, że klient jest gotowy ponieść koszta :-). Poza tym jest util
zwracający policy do haseł (w postach powyżej), zatem to tylko opcja
którą przy okazji znalazłem - ale wtedy trzeba samemu zaimplementować
obsługę.

> To co proponujesz, to właśnie może sprowadzić Bartka na złą drogę -
> wyjdzie nowy Liferay i kod który wkleiłeś będzie do przepisania od
> nowa, bo zmieni się np. mechanizm walidowania reserved screen names.
> Albo dojdzie nowy mechanizm cache'owania? Albo nowa lista brzydkich
> wyrazów w loginach, których nie wolno używać - korzystająca z
> globalnego słownika? I co wtedy?

Wtedy Bartek zarobi dużo kasy na płatnej aktualizacji software'u który
napisał ;-) a nam postawi piwo. To problem wirtualny w momencie gdy
między wersją 5 a 6 były różnice w UserLocalServiceUtil (np. addUser -
zupełnie inna sygnatura i inne rzucane wyjątki). Tak zdaję sobie
sprawę, że nie tylko na tym polega walidacja (też patrzyłem na kod
źródłowy Liferaya gdy doradzałem taki sposób wyciągnięcia danych).
Zawsze można użyć ServiceBuildera i utworzyć nowy LocalServiceUtil a
następnie używać go do woli wraz z innymi. W tym przypadku można także
opakować owo nieszczęsne PwdToolkitUtil. Chociaż w tym momencie także
nie masz gwarancji, że po aktualizacji nie zmieni się zachowanie
PwdToolkitUtil... bo to nie jest API upublicznione... i co
wtedy? :-).

Pozdrawiam
Sebastian Konkol

[Tomek Lipski]

On Feb 27, 5:32 pm, "sebastian.konkol" <sebastian.kon...@gmail.com>
wrote:

> Odpowiadając:
>
> > Hmm, ta metoda niestety nie odpala password policy pod kątem innym niż
> > obecność takiego hasła poprzednio u użytkownika. Więc przy zakładaniu
> > nowego konta, będzie ona dosyć krótka.
> > Pełna logika walidacji hasła użytkownika znowu jest w
> > UserLocalServiceImpl.validatePassword - ona woła wspomniane (i
> > dostępne tylko w portal-impl niestety) PwdToolkitUtil.validate, które
> > woła
> > odpowiedni toolkit walidujący hasła (są 2 implementacje z tego co
> > widzę - regexp oraz passwordpolicy).
>
> > Chociaż hasło to ja bym generował i wysyłał ludziowi na emaila -
> > łatwiej, prościej i szybciej. Ale wiadomo - wymaganie biznesowe święte
> > jest ;-)
>
> Też samemu bym generował hasło, ale skoro takie mają wymagania to
> znaczy, że klient jest gotowy ponieść koszta :-). Poza tym jest util
> zwracający policy do haseł (w postach powyżej), zatem to tylko opcja
> którą przy okazji znalazłem - ale wtedy trzeba samemu zaimplementować
> obsługę.

Wiadomo - policy można wczytać, ale wtedy reimplementujemy to co jest
napisane w Liferayu (tylko ukryte).

>
> > To co proponujesz, to właśnie może sprowadzić Bartka na złą drogę -
> > wyjdzie nowy Liferay i kod który wkleiłeś będzie do przepisania od
> > nowa, bo zmieni się np. mechanizm walidowania reserved screen names.
> > Albo dojdzie nowy mechanizm cache'owania? Albo nowa lista brzydkich
> > wyrazów w loginach, których nie wolno używać - korzystająca z
> > globalnego słownika? I co wtedy?
>
> Wtedy Bartek zarobi dużo kasy na płatnej aktualizacji software'u który
> napisał ;-) a nam postawi piwo. To problem wirtualny w momencie gdy
> między wersją 5 a 6 były różnice w UserLocalServiceUtil (np. addUser -
> zupełnie inna sygnatura i inne rzucane wyjątki). Tak zdaję sobie
> sprawę, że nie tylko na tym polega walidacja (też patrzyłem na kod
> źródłowy Liferaya gdy doradzałem taki sposób wyciągnięcia danych).
> Zawsze można użyć ServiceBuildera i utworzyć nowy LocalServiceUtil a
> następnie używać go do woli wraz z innymi. W tym przypadku można także
> opakować owo nieszczęsne PwdToolkitUtil. Chociaż w tym momencie także
> nie masz gwarancji, że po aktualizacji nie zmieni się zachowanie
> PwdToolkitUtil... bo to nie jest API upublicznione... i co
> wtedy? :-).

Ok - zmiana sygnatury metody to jedno, zmiana logiki biznesowej to
drugie - logika może się zmienić "po cichu", bez modyfikacji w
wystawionym interfejsie - i wtedy nikt nie wie, że się zmieniła.
Zmiana sygnatury - to się łatwo zauważa w Javie - w najgorszym razie
przy 1. uruchomieniu kodu. Ale tak - grzebanie żeby użyć metody
protected też nie jest w 100% elegenckie.

Service Builder - wydaje mi się, że nowy LocalServiceUtil nie zobaczy
klas z portal-impl (PwdToolkitUtil tam siedzi) - unless zrobisz go
jako Ext a nie Hook - popraw mnie, jeśli się mylę.
Deployujemy go jako osobny war, więc ma swój classpath a w globalnej
ścieżce kontenera mamy tylko portal-service.jar (i oczywiście
JSR168/286).

t