Как кэшировать формы с помощью обратного прокси-сервера и работать с устаревшими токенами форм?

Когда API формы генерирует форму, он также генерирует токен, который передается с формой в скрытом поле и ожидается, что он будет возвращен обратно. Если это так, форма обрабатывается.

Если визуализированная форма где-нибудь будет кэширована, скажем, Varnish , этот механизм сломается. Первый пользователь, отправляющий форму, будет использовать токен, и последующие попытки использовать форму будут отклонены.

Какие стратегии доступны для поддержания работы форм при кэшировании их визуализированной формы?

caching forms

— Letharion
источник

Ты уверен насчет этого? Я построил сайты с формами и обратными прокси и не видел проблем. В общем, единственное, что вам нужно следить, - это следить за тем, чтобы страницы результатов не кэшировались.

— Альфред Армстронг

Мне бы очень хотелось, чтобы меня ошиблись, так как это решило бы мою проблему, но да, я уверен. :) Проверьте функции form_ {g, s} et_cache для деталей.

— Летарион

Для анонимных пользователей я уверен, что страницу с формой можно безопасно кэшировать. Для неанонимных пользователей обратные прокси-серверы проблематичны в любом случае.

— Альфред Армстронг

(Жетоны генерируются только тогда, когда у пользователя есть идентификатор.)

— Альфред Армстронг

Ах, это имеет смысл. К сожалению, мои пользователи в этом случае проходят проверку подлинности. Возможно, вопрос должен быть переформулирован, чтобы включить это.

— Летарион

Ответы:

Я использую BOA для своих сайтов, но по умолчанию BOA просто отключает кэширование на лету для отправки форм. Помимо моего реального опыта, я столкнулся с однолетним искусством по поводу того, как Почта Новой Зеландии работает с Drupal & Varnish и проблемой с токенами форм. Святой Джон Уэйн, его обязательно нужно прочитать для кеширования Drupal - действительно. Ориентируясь только на вопрос формы:

Последним элементом нашей головоломки является модуль Cookie Cache Bypass Advanced , который автоматически устанавливает специальный файл cookie NO_CACHE каждый раз, когда пользователь отправляет форму POST на сайте, включая такие вещи, как форма входа в систему. Наш Varnish настроен для обхода кэша страниц (но не кэша ESI), когда он видит этот файл cookie.

Вы также можете отключить токены форм, когда в X_FF не требуется получение XSRF (unset ($ form ['# token']);) или ($ form ['# token'] = FALSE;)

An Acquia Drupal производительности статья выдвигает Drupal модуль Authcache , но , читая документ на Authcache, она работает кэширование с держателем места для формы (не кэширует форму):

Authcache пытается перехватить любое настроенное содержимое и установить заполнитель в HTML. Затем после загрузки страницы обратный вызов Ajax используется для извлечения пользовательских данных и заполнения заполнителей, динамически обновляя HTML-код страницы.

Текущие заполнители Authcache: токены форм (только для зарегистрированных пользователей; требуется> Drupal для предотвращения атак подделки межсайтовых запросов)

Стратегия такова: кешировать все, кроме формы . Итак, обращаясь ко всему остальному: может, Varnish вообще не используется, Memcache & Redis? Моя стратегия состояла бы в том, чтобы использовать то, что предлагает BOA, потому что я использую BOA, и мастера за ним ( omega8.cc ) знают на тонну больше, чем я. Я не думаю, что существует внешний кеш, который решает проблему. Кажется, все они обходят форму.

Выполните частичное кэширование с вышеупомянутым authcache и с тонко настроенными представлениями и панелями, как упомянуто в статье NZ Post и описано мозговым трастом в Wunderkraut - это старое, но решает проблему.

Используйте Drupal ESI Module и Varnish частично совместим с ESI):

ESI - или Edge Side Includes - это высокопроизводительное решение для кэширования для аутентифицированных пользователей, но может быть полезно и для анонимных пользователей.

Как правило, страницы, которые персонализированы для аутентифицированных пользователей (даже незначительных персонализаций, таких как блок с надписью «Зарегистрирован как manarth»), не позволяют обратным прокси-серверам (которые могут легко работать в 100 раз быстрее, чем Drupal) кэшировать страницу, поскольку сообщения предназначенный для одного пользователя, может быть виден другим.

Надеюсь, что это более полезно.

— Том
источник

Беглый взгляд на код показывает, что модуль ESI вообще ничего не делает в отношении проверки формы; не упоминается ни об обработке токенов, ни о каких-либо интересных формах. Возможно ли, что вы просто не кэшировали никаких форм, требующих аутентификации на лаке, и именно поэтому вы никогда не сталкивались с этой проблемой?

— Летарион

Оказывается, это именно то, что происходит, BOA на ходу обходит кэш внешнего интерфейса для форм (извините за мой ранее неполный / неправильный ответ). В моем ответе ESI по-прежнему является важной частью стратегии «кэшировать все, кроме», даже если она не решает напрямую.

— Том

Эта новостная статья была действительно интересной. Однако, насколько я могу судить, он решает только проблему с токеном: «В тех случаях, когда вы уверены, что защита XSRF не важна ... Drupal предоставляет механизм для отключения токенов форм», что бесполезно в мое дело.

— Летарион

Хотя много полезной информации, и определенно другие смогут применить ее к своим проблемам. +1, и так как осталось всего час, я тоже могу узнать награду. :)

— Летарион

Одним из возможных решений было бы отключить токен вместе с $form[‘#token’] = FALSE;последующим переопределением обратного вызова submit, вместо того, чтобы фактически публиковать комментарий, восстановить исходную форму с токеном и попросить пользователя подтвердить сообщение.

Если пользователь поддерживает ECMAScript , можно улучшить взаимодействие с пользователем, имея ресурс сервисов, который предоставляет генерацию новых токенов формы и вставляет соответствующую форму в form_cache. Затем, как только пользователь сфокусируется на форме и, следовательно, захочет отправить ее, отключите кнопку отправки, извлеките новый токен и вставьте его в уже обработанную форму, а затем снова включите кнопку отправки.

— Letharion
источник