xmoonlight, я просто еще не совсем понял какую задачу решаем. Что запрос отправляет реальный живой человек? Или что запрос приходит от того, от кого мы думаем, что он приходит?
Если первое, то капча - отличное предложение.
Если второе, то как бы ни хотелось, надежно убедиться, что запрос идет из JS с какого-то конкретного домена невозможно в принципе. Соответственно, единственный вариант: регистрировать приложения, где будет размещен виджет, выдавать ему секрет и делать отправку писем через этот самый сервер, т.е. не только на стороне клиента, но это усложнит установку виджета. Но тогда у автора вопроса будет уверенность, что запрос действительно пришел от того, от кого пришел. Но это, тем не менее, не будет гарантировать, что запрос на отправку письма пришел от реального человека, а не от машины.
А как это все спасет от запроса с сервера? Это все только hardening, на это нельзя полагаться. Дайте мне скрипт этого решения и я обойду его за секунду:
1) hash я получаю со страницы с публичной страницы с iframe.
2) На какой стороне формируется токен на основе ip, рефера и hash-ключа? И как он может формироваться в момент отправки формы если браузер ничего не знает про ip?
Если же токен формируется запрос на сторонний сервер, то я просто могу выставить кастомный referer, сделать запрос через tor или любой прокси и передать hash-ключ с первого шага.
Соглашусь с Андреем, по-другому задача не решается.
Любой запрос, который можно отправить с браузера, можно отправить и с сервера. Поэтому нужно четко понимать задачу: если требуется убедиться, что отправку производит человек, то капча - ваше решение.
Если требуется убедиться, что отправка идет именно с того приложения, которому вы сгенерировали токен, то нужно отдавать iframe по этому токену, но тогда любой другой сможет этот токен себе скопировать и использовать.
Сессия, которую вы упоминаете, тоже не поможет даже если ее хранить не на сервере, а на стороне клиента в виде jwt-токена или любым другим образом, который криптографически защищает содержимое токена. Потому что любой другой на стороне сервера просто запроси этот же айфрейм, получит токен и отправит его.
Задача, которую вы сейчас поставили, не решается, email по-любому нужно будет отправлять с сервера, где можно хранить ключи, а дальше авторизуйте приложение как хотите, хоть oauth2 используйте.
Ну да, я тут стратегию предложил, а дальше уже дело выбрать какое-то одно действие, которое по ощущениям сейчас будет самым полезным и выработать какую-то тактику :)
Про архитектуру Фаулер и банда четырех наше все. В исходниках фреймворках тоже хорошо бы поковыряться, а еще лучше законтрибьютить что-нибудь. На фронт-енде особенно важно иметь хорошее понимание архитектуры, фреймворки там быстро меняются и нужно уметь отличить полезное от неполезного и быстро войти в новый фреймворк.
Не за что. Happy designing! У вас тоже, смотрю, получилось, что проверка на права находится вне моделей и это, в общем-то так и должно быть, это правильный шаг на мой взгляд.
Написано
Войдите на сайт
Чтобы задать вопрос и получить на него квалифицированный ответ.
1. Лучше капчи пока ничего не придумали.
2. Да тут ничего не поможет, только запрос с сервер-сайда. И привязка не к домену, а к выданным кредам.