Mieszany HTTP / HTTPS - problem

Chciałbym ustawić mieszany http / https na całej aplikacji.
Np HTTPS ma być włączany dla edycji danych użytkownika, akcji związanych z uwierzytelnieniem(rejestracja, reset hasła) itd.
Pozostałe akcje powinny mieć wymuszony HTTP.

Przy czym jeśli user się zaloguje prawidłowo to powinno go przekierować na stronę główną ale na HTTP.

Samo korzystanie z różnych gemów np rack-ssl, ssl-requirement nie rozwiązuje problemu bo po zalogowaniu nadal jedzie na całej aplikacji po HTTPS(a powinno tylko na niektórych).

Czy macie jakieś sprawdzone rozwiązania do tych kwestii(poza ręcznym przepisywaniem wszystkich linków z http lub https)?

/edit
Pracuje na RoR 3.0.9.

A skąd masz wymaganie, żeby użyć HTTP a nie jechać w całości po HTTPS?

z readme ssl-requirement:

Aczkolwiek zawsze zastanawiało mnie, po jaką cholerę gdziekolwiek wymuszać http

Widzi mi sie klienta.

Zauważ także że większe serwisy np aledrogo, amazon też mają mieszany HTTP/HTTPS.

Hmm. Nie wiem czy aktualne nadal wszystkie punkty :stuck_out_tongue:

[quote]you lose a lot of features with https (mainly related to performance)

Proxies cannot cache pages
You cannot use a reverse proxy for performance improvement
You cannot host multiple domains on the same IP address
Obviously, the encryption consumes CPU

Maybe that’s no problem for you though, it really depends on the requirements[/quote]

[/quote]
O tego gema chodzi?
https://github.com/retr0h/ssl_requirement

zadaniem profesjonalisty jest czasem wybijać z głowy głupie pomysły.

w tak ogromnych serwisach faktycznie niebagatelną rolę mogą odgrywać minusy, które wypisałeś - przy czym zastanów się, czy piszesz faktycznie coś tak dużego, gdzie to faktycznie jest problem.

[quote]O tego gema chodzi?
https://github.com/retr0h/ssl_requirement[/quote]
Tak, tu zostało przeniesione oficjalne repo z rails/ssl_requirement

Rozumiem, że casus Fejsbuka i innych jemu podobnych portali jest dla Twojego klienta niegroźny?
A propos przedstawionych argumentów przeciw używaniu https po zalogowaniu użytkownika:
ad. 1) zwykle po zalogowaniu dane wysyłane przez serwer są spersonalizowane, więc i tak nie ma sensu ich cache’ować
ad. 3) jeśli w ogóle chcesz używać https to i tak musisz mieć osobne domeny
ad. 4) obciążenie CPU przy enkrypcji nie jest istotnym składnikiem - najważniejszy jest czas nawiązania pierwszego połączenia (i kolejnych - zależy od długości sesji i keep-alive)

Więc osobiście uważam, że względy bezpieczeństwa powinny przeważyć na korzyść https w większości scenariuszy (oczywiście tylko po zalogowaniu użytkownika).
Tym bardziej, że przedstawiasz tutaj scenariusz czarnej listy niebezpiecznych działań (tylko niektóre akcji byłyby szyfrowane, zamiast - tylko niektóre akcje byłyby nieszyfrowane), który w zasadzie zawsze prowadzi do pominięcia szyfrowania niby nieistotnej operacji, która może stać się wektorem ataku.