Sesje Railsowe - aktualne praktyki

84

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?

ruby-on-rails ruby session cookies Lukas
źródło
1
Jakie są obecne przemyślenia na temat używania Memcached do przechowywania sesji?
Lukas,
Powiązane: rails 4.0, rake db: session: create .

Odpowiedzi:

102

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.

Szyny 3

config / initializers / session_store.rb:

Rails.application.config.session_store :active_record_store

Szyny 2

config / environment.rb:

config.action_controller.session_store = :active_record_store
Wulkaniczny
źródło
2
Ostatnio słyszałem, że sesje ARstore są bardzo wolne. ktoś wie o benchmarkach?
Lukas,
4
Jeśli obserwujesz wzrost tabeli sesji i skonfigurujesz zadanie, aby odpowiednio je przyciąć, nie będziesz mieć problemów z wydajnością.
Bill Leeper,
3
Czy to koliduje z devise?
David Mauricio,
4
Tutaj, Rails 3.2, jest to coś w rodzaju TheNameOfMyApplication :: Application.config.session_store: active_record_store
Eduardo
3
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 .
53

Pliki cookie są domyślnie szyfrowane w Rails 4

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ój user_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_tokeni secret_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.

Magazyn sesji Active Record jest przestarzały w Rails 4

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 .

Bieżące najlepsze praktyki sesji Railsowych

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 .

Społeczność
źródło
9

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 .

Tilendor
źródło
4

FWIW, rails 3.1 sugeruje bieganie 

rails generate session_migration

Jednak generuje to dokładnie taką samą migrację, jak 

rake db:sessions:create
Nate Milbee
źródło
Z tego samego powodu zadanie prowizji 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
skos
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 .
2

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.

Yarin
źródło