Dobra praktyka - różne assety w zależności od 'stanu' aplikacji

Dzisiaj mnie naszła taka myśl.
Mam aplikację, która wita użytkownika prośbą o podanie loginu i hasła. Ponieważ nie trafiłem na tutorial mówiący o takim problemie jaki wymyśliłem to robiłem bez pomyślunku. No to dzisiaj biorę zaglądam w źródło strony (z ekranem logowania) - klikam na plik .js i zaczynam się orientować co ta aplikacja robi. Gorzej - widzę tam ajaxowe wywołania itp.- no i pomimo iż niezalogowany człowiek i tak tego nie wywoła, to jednak pokazywanie tego całemu światu uważam, za może nie tyle zagrożenie bezpieczeństwa aplikacji (chociaż oczywiście atakujący może próbować znając z .js nazwy kontrolerów ew. akcji i może wykryć mój ewentualny błąd) co za bardzo nieprofesjonalne podejście. Po to część aplikacji jest ukryta przed osobami postronnymi, żeby nie miały najmniej o tej aplikacji wiedzy…

No dobrze, zatem jak powinno się taki problem rozwiązać?

W sumie pisząc tego posta sam wykombinowałem, że należy po prostu zrobić kilka różnych ‘wersji’ app/assets/javascript/application.js - czyli plików o różnych nazwach i tam zrobić require tylko na konkretne pliki - nie na całe drzewo. Później w widoku standardowo leżącym gdzieś w view/layouts/application.html.* w zależności od poziomu dostępu robić javascript_include_tag z odpowiadającym plikiem .js

Czy to jest prawidłowe rozumowanie? Czy jest tu coś do dodania?

PS. czy da się na podstawie danych sesji w podobny sposób ustalać routing?
PS2. w momencie gdy wpadłem jak to rozwiązać - chciałem usunąć post - ale może komuś się to przyda (bo tak jak ja o tym nie pomyślał), a może i ja dowiem się jeszcze czegoś dodatkowego.

Pozdrawiam!

Najłatwiej będzie rozdzielić na dwa katalogi i dla widoku z logowaniem ładować application.js z jednego, a dla zamkniętej części drzewo z drugiego. Czyli chyba dobrze to wymyśliłeś.
A propos js’ów polecam blog tego pana - http://brandonhilkert.com/blog - gdzieś ma artykuł o trzymaniu jsów jako widoki do swoich htmlowych odpowiedników, stosujemy w dwóch projektach i jak na razie spisuje się wyśmienicie.

Moim zdaniem rozwiązujesz problem, które nie ma. Zalogowany użytkownik dalej zobaczy ten cały javascript i wtedy wracasz do punktu wyjścia. Trzeba się z tym pogodzić, że użytkownik ma dostęp do wszystkiego co dostaje przeglądarka. Czy zmniejszenie skali użytkowników, którzy zobaczą ten javascript zwiększa bezpieczeństwo?

Nie do końca. Bo ja nie chcę żeby każdy postronny mógł zobaczyć kod - czytaj, osoba, która się nie uwierzytelniła. Podobnie jak zwykły użytkownik nie powinien widzieć części dla admina. Z plików .js można wydedukować co robi aplikacja, co może admin itp. Jeżeli mam pomieszczenie, do którego dostęp jest ograniczony to raczej nie robię odsłoniętych okien na ulicę, gdzie każdy Zenek Bębenek może zaglądać :slight_smile:
Ok, nie zawsze musimy popadać w paranoję, ale myślę, że warto się czasem nad tym zastanowić.

Prawdę mówiąc, wydaje mi się, że nawet gdyby użytkownik widział panel admina, to nie powinno z tego nic złego przyjść. Właśnie na tym polega dobrze napisany backend, żeby każda potencjalnie niebezpieczna akcja była autoryzowana. Na tym polegają też aplikacje open-source. Możesz pokazać użytkownikowi nawet cały kod, pod warunkiem, że jest dobrze napisany [no i nie pokazujesz w nim sekretów :P]

Security through obscurity would be burying your money under a tree. The only thing that makes it safe is no one knows it’s there. Real security is putting it behind a lock or combination, say in a safe. You can put the safe on the street corner because what makes it secure is that no one can get inside it but you

If someone discovers the password, you can just change the password, which is easy. If someone finds the location, you need to dig up the money and move it somewhere else, which is much more work. And if you use security by obscurity in a program, you would have to rewrite the program.

Proponuje spojrzeć na http://webpack.github.io/