Czy ktoś ma jakieś „najlepsze praktyki” dotyczące Railsów i sesji? Domyślnym typem sesji dla Rails 3 jest nadal CookieStore, prawda? Używałem SqlSessionStore przez jakiś czas i działało dobrze, ale mogę odejść od tego na korzyść CookieStore.
Czy nadal nie jest dobrym pomysłem używanie CookieStore do przechowywania poufnych informacji, nawet z solonymi informacjami, czy też lepiej jest przechowywać je w bazie danych?
Odpowiedzi:
Używaj bazy danych do sesji zamiast domyślnych plików cookie, które nie powinny być używane do przechowywania wysoce poufnych informacji
Utwórz tabelę sesji za pomocą
rake db:sessions:create
Uruchom migrację
rake db:migrate
Upewnij się, że również nakazujesz railsom używanie ActiveRecord do zarządzania Twoimi sesjami.
config / initializers / session_store.rb:
Rails.application.config.session_store :active_record_store
config / environment.rb:
config.action_controller.session_store = :active_record_store
rake db:sessions:createJest przestarzała i usuwane w Rails 4, ponieważ nie skaluje się dobrze do zastosowań z wielu użytkowników (zbyt wiele baz danych odczytuje i zapisuje). Zobacz rails 4.0, rake db: session: create .
W Rails 4 ciasteczka CookieStore są domyślnie szyfrowane i podpisywane:
Jeśli tylko
secret_tokenustawiłeś, Twoje pliki cookie będą podpisane, ale nie zaszyfrowane. Oznacza to, że użytkownik nie może zmienić swojego,user_idnie znając tajnego klucza aplikacji, ale może łatwo odczytać swójuser_id. Było to domyślne ustawienie dla aplikacji Rails 3.Jeśli
secret_key_baseustawiłeś, Twoje pliki cookie będą zaszyfrowane. To idzie o krok dalej niż podpisane pliki cookie, ponieważ zaszyfrowane pliki cookie nie mogą być zmieniane ani odczytywane przez użytkowników. Jest to domyślne ustawienie począwszy od Rails 4.Jeśli masz oba
secret_tokenisecret_key_baseustawione, Twoje pliki cookie będą zaszyfrowane, a podpisane pliki cookie wygenerowane przez Rails 3 będą w przejrzysty sposób odczytywane i szyfrowane, aby zapewnić płynną ścieżkę aktualizacji.
Ta odpowiedź jest obecnie nieaktualna w odniesieniu do Rails 4. Magazyn sesji Active Record został wycofany i usunięty z Railsów, więc następujące generatory nie będą już działać:
rake db:sessions:create
rails generate session_migration
Wskazano na to w tej odpowiedzi . Powodem, dla którego magazyn sesji Active Record został wycofany, jest to, że odczyty / zapisy w bazie danych nie są dobrze skalowane, gdy masz dużą liczbę użytkowników uzyskujących dostęp do aplikacji, jak podano w tym wpisie na blogu :
... jednym z głównych problemów z magazynem sesji Active Record jest to, że nie jest skalowalny. Powoduje to niepotrzebne obciążenie Twojej bazy danych. Gdy aplikacja otrzymuje duży ruch, tabela bazy danych sesji jest stale bombardowana operacjami odczytu / zapisu.
Od wersji Rails 4 magazyn sesji Active Record został usunięty z podstawowego środowiska i jest obecnie przestarzały.
Jeśli nadal chcesz korzystać z magazynu sesji Active Record, jest on nadal dostępny jako klejnot .
Aby uzyskać więcej aktualnych najlepszych praktyk dotyczących sesji Ruby on Rails, radzę zapoznać się z najnowszymi wersjami Przewodnika po bezpieczeństwie Ruby on Rails .
Nie sądzę, aby coś się zmieniło w sposobie obsługi sesji opartych na plikach cookie. Podchodź sceptycznie do wszystkiego, co wykracza poza kontrolę serwera (pliki cookie, posty formularzy itp.) To ogólna zasada tworzenia stron internetowych.
Jeśli chodzi o szyfrowanie, nie wiem, czy coś się zmieniło na tym froncie.
Coś, o czym należy pamiętać w przypadku magazynu plików cookie, to ograniczenie ilości danych i problem z tym, że dane te będą przesyłane kablem w każdym żądaniu, gdzie jako baza danych przesyła tylko identyfikator, a dane pozostają na serwerze .
FWIW, rails 3.1 sugeruje bieganie
rails generate session_migration
Jednak generuje to dokładnie taką samą migrację, jak
rake db:sessions:create
db:sessions:createwywołuje teraz bezpośrednio session_migrationgenerator. task: create =>: środowisko nie podnosi "Zadanie niedostępne dla tej bazy danych (brak obsługi migracji)", chyba że ActiveRecord :: Base.connection.supports_migrations? require 'rails / generators' Rails :: Generators.configure! require 'rails / generators / rails / session_migration / session_migration_generator' Rails :: Generators :: SessionMigrationGenerator.start [ENV ["MIGRATION"] || "add_sessions_table"] end
rake db:sessions:createI rails generate session_migrationgeneratory są przestarzałe i usuwane w Rails 4, ponieważ nie skalują się dobrze do zastosowań z wielu użytkowników (zbyt wiele baz danych odczytuje i zapisuje). Zobacz rails 4.0, rake db: session: create .
Domyślne ustawienia Railsów wydają mi się całkiem dobre - CookieStore jest szybki i powinien obejmować większość przypadków użycia. Jasne, że masz ograniczenie do 4kb, a twoje dane będą widoczne dla użytkownika, ale sposobem Railsów jest używanie sesji tylko do takich rzeczy, jak identyfikatory całkowite i podstawowe wartości ciągów - Jeśli próbujesz przechowywać obiekty lub wysoce poufne informacje w sesji prawdopodobnie robisz to źle.