Chcialem poruszyc troche filozoficzny temat – umiejscowienie panelu admin.
Innymi slowy, Panel admin razem czy osobno z właściwą aplikacją? Dlaczego coś, do czego
z definicji powinien być ograniczony dostęp miałobybyć publicznie udostępnione.
Oba rozwiazania maja wady i zalety:
Panel admin razem z właściwą aplikacją (standardowo)
Za: brak potrzeby synchronizowania modeli
Przeciw: “bezpieczeństwo”
Panel admin osobno (przy większej skali przedsięwzięcia milej widziane)
Za: zwiekszone bezpieczenstwo: np. przy dostepie przez VPN
Przeciw: potrzeba synchronizowania modeli
Jesli zechcialbym miec admin panel wydzielony, jak efektywnie synchronizować modele z główną aplikacją?
Oto sposoby rozwiązania tego problemu jakie wymyslilem:
a) Dwa branche(master, master-admin), master to głowna aplikacja, branch master-admin taki sam kod jak w master ale dodatkowo wzbogacony o kod panelu administracyjnego (deploy admina z brancha master-admin, wlasciwej aplikacji z brancha master)
W razie zmian w master merguje, tak aby zmiany pojawily sie w master-admin.
b) “Wspolne” modele przetrzymywane jako gem. Tutaj widzę utrudniony development.
c) Jakiś skrypt do “ynteligentnej” synchornizacji.
Macie jakies pomysły / przemyślenia odnośnie tego tematu?
Dawno temu w jednej z aplikacji mieliśmy to rozwiązane tak, że katalog do modeli panelu admina był po prostu symlinkiem do modeli głównej aplikacji, plus do tego parę innych drobnych haków.
Generalnie nie polecam takiego rozwiązania, moim zdaniem jest to niepotrzebne dokładnie sobie pracy.
[quote=mkacz]a) Dwa branche(master, master-admin), master to głowna aplikacja, branch master-admin taki sam kod jak w master ale dodatkowo wzbogacony o kod panelu administracyjnego (deploy admina z brancha master-admin, wlasciwej aplikacji z brancha master)
W razie zmian w master merguje, tak aby zmiany pojawily sie w master-admin.
b) “Wspolne” modele przetrzymywane jako gem. Tutaj widzę utrudniony development.
c) Jakiś skrypt do “ynteligentnej” synchornizacji.[/quote]
Żadne z powyższych. Jeśli chcesz mieć w oddzielnej aplikacji, zrób sobie mniej więcej coś takiego w application.rb:
# Custom directories with classes and modules you want to be autoloadable.
config.autoload_paths += %W(#{config.root}/../app/models #{config.root}/../app/uploaders #{config.root}/../lib #{config.root}/../app/mailers)
Tutaj akurat jest przykład admina jako oddzielna aplikacja w tym samym katalogu.
Wtedy można by jeszcze zrobić jakieś “wspólne” miejsce na trzymanie listy requires itp., ale to podejście nie jest tak upierdliwe jak symlinki, czy o zgrozo synchronizacja modeli.
Nie rozumiem jak umieszczanie panelu admina w osobnej aplikacji zwiększa bezpieczeństwo.
Przy małych aplikacjach: trzymać razem z całą resztą, po prostu osobny namespace. Duże trzeba i tak podzielić na kilka mniejszych i wtedy można wydzielić m.in. panel admina.
Nie rozumiem jak umieszczanie panelu admina w osobnej aplikacji zwiększa bezpieczeństwo.[/quote]
Już objaśniam o co mi chodzi. Panel admin, z definicji udostępnia interfejs do wykonywania bardziej uprzywilejowanych operacji. Nie udostępniając go publicznie zmniejszamy szanse, ze ktoś uzyska do niego niepowołany dostęp.
@sharnik: masz może dobry pomysl, jak przy dzieleniu dużej aplikacji na kilka mniejszych utrzymywać/synchronizować część wspolną dla każdej(modele)?
To w żaden sposób nie jest związane z tym czy panel jest w osobnej aplikacji, czy nie. Wystarczy dodać jakiś Admin::BaseController po którym będą dziedziczyć pozostałe i w nim określić zasady dostępu.
SOA. Dzielisz aplikację na osobne serwisy, które nie współdzielą modeli, a jedynie komunikują się ze sobą przez jakieś wewnętrzne API. Jakikolwiek kod, który muszą współdzielić wyciągasz do osobnego gema, którego używasz przez bundler jeśli potrzeba.
Nie rozumiem jak umieszczanie panelu admina w osobnej aplikacji zwiększa bezpieczeństwo.[/quote]
To dość oczywiste - uruchamiasz aplikację administracyjną na subdomenie, do której w iptables ograniczasz dostęp z określonych IP. Rozwiązanie znane, stosowane i zalecane w Rails security guide (ostatni punkt).
Oczywiście nie wszędzie ma to uzasadnienie (aplikacja do blogów, etc.) Ale myślę, że w każdym poważniejszym zastosowaniu warto wziąć pod uwagę to rozwiązanie.
[quote=apohllo]To dość oczywiste - uruchamiasz aplikację administracyjną na subdomenie, do której w iptables ograniczasz dostęp z określonych IP. Rozwiązanie znane, stosowane i zalecane w Rails security guide (ostatni punkt).
Oczywiście nie wszędzie ma to uzasadnienie (aplikacja do blogów, etc.) Ale myślę, że w każdym poważniejszym zastosowaniu warto wziąć pod uwagę to rozwiązanie.[/quote]
Znane, stosowane, zalecane, ale nie wymaga wydzielania osobnej aplikacji administracyjnej. Możesz ustawić subdomenę dla panelu admina w routes.rb i masz dokładnie taki sam efekt.
Stąd moje pytanie co daje wydzielenie panelu administracyjnego do osobnej aplikacji, czego nie można uzyskać w prosty sposób bez wydzielania.
[quote=sharnik][quote=apohllo]To dość oczywiste - uruchamiasz aplikację administracyjną na subdomenie, do której w iptables ograniczasz dostęp z określonych IP. Rozwiązanie znane, stosowane i zalecane w Rails security guide (ostatni punkt).
Oczywiście nie wszędzie ma to uzasadnienie (aplikacja do blogów, etc.) Ale myślę, że w każdym poważniejszym zastosowaniu warto wziąć pod uwagę to rozwiązanie.[/quote]
Znane, stosowane, zalecane, ale nie wymaga wydzielania osobnej aplikacji administracyjnej. Możesz ustawić subdomenę dla panelu admina w routes.rb i masz dokładnie taki sam efekt.
Stąd moje pytanie co daje wydzielenie panelu administracyjnego do osobnej aplikacji, czego nie można uzyskać w prosty sposób bez wydzielania.[/quote]
Fakt, nie wziąłem tego pod uwagę. Ale zastosowanie osobnej aplikacji ma jeszcze inne zalety.
Np. w bardziej paranoicznych kontekstach możesz mieć inne uprawnienia w bazie danych dla poszczególnych aplikacji, żeby np. uniemożliwić usuwanie (na poziomie DB) określonych rekordów dla aplikacji publicznej. Ponadto jeśli zostanie wykryty jakiś błąd na poziomie stosu Rails, który np. umożliwiłby wykonanie akcji z innego kontrolera albo obejście constraintów w Routs.rb to jeśli masz dwie oddzielne aplikacje, to tego rodzaju błędu nie będzie się dało wykorzystać. Wcale by mnie nie zdziwiło, gdyby coś takiego dało się znaleźć - ostatnio np. odkryłem, że migracje nie przechodzą z powodu złego dopasowania wyrażenia regularnego.
To jest bardziej kwestia dodawania kolejnych poziomów bezpieczeństwa, z założeniem, że mimo naszych najlepszych chęci one nie działają tak jak byśmy chcieli (kumpel opowiadał mi np. o błędzie w iptables, który pozwalał omijać niektóre filtry) i jeśli oprzemy się tylko na jednym rozwiązaniu, to zawsze może okazać się, że ono jednak nie jest doskonałe. A Railsy jak wiemy doskonałe nie są.
Co jest nie tak z podaniem ścieżek w config.autoload_paths?