Передача конфиденциальных и коротких данных на внешние ссылки
Я вижу, что некоторые из вышеперечисленных ответов сейчас немного устарели. С моей точки зрения, и я ежедневно работаю с Solr (Cloud и non-Cloud) и ElasticSearch, вот некоторые интересные отличия:
- Сообщество: у Solr есть больший, более зрелый пользователь , dev и сообщество разработчиков. ES имеет меньшее, но активное сообщество пользователей и растущее сообщество участников
- . Зрелость: Solr более зрелая, но ES быстро растет, и я считаю ее стабильной
- Производительность: сложная судить. Мы не проводили прямых тестов производительности. Человек в LinkedIn сравнивал Solr vs. ES с Sensei один раз, но исходные результаты следует игнорировать, потому что они использовали не экспертную настройку для Solr и ES.
- Дизайн: Люди любят Solr. Java API несколько подробный, но людям нравится, как он складывается. Код Solr, к сожалению, не всегда очень красив. Кроме того, ES имеет осколки, репликацию в реальном времени, встроенную документацию и маршрутизацию. Хотя некоторые из них существуют и в Solr, он чувствует себя немного как последующий.
- Поддержка: есть компании, предоставляющие техническую и консультационную поддержку для Solr и ElasticSearch. Я думаю, что единственная компания, которая обеспечивает поддержку для обоих, - это Sematext (раскрытие: I'm Sematext основатель)
- Масштабируемость: оба могут быть масштабированы до очень больших кластеров. ES легче масштабировать, чем версия Solr версии 4.0 до Solr 4.0, но с Solr 4.0 это уже не так.
Для более полного освещения темы Solr vs. ElasticSearch см. http://blog.sematext.com/2012/08/23/solr-vs-elasticsearch-part-1-overview/ . Это первое сообщение в серии сообщений от Sematext, где делается прямая и нейтральная сопоставление Solr vs. ElasticSearch. Раскрытие информации: Я работаю в Sematext.
1 ответ
Я немного озадачен тем, как выглядит ваш пользовательский интерфейс, но я бы держал всю эту информацию вне ссылки и обязательно делал подтверждение в POST (так как некоторые браузеры предварительно загружают ссылки, которые могут привести к непреднамеренным покупкам если вы сохраните это как ссылку). Вместо этого я бы использовал помощник button_to.
Я не уверен, как вы отслеживаете порядок, находится ли он в базе данных или сеансе или что. Поэтому вам, возможно, придется немного изменить это, чтобы пропустить правильные параметры.
https://apidock.com/rails/ActionView/Helpers/UrlHelper/button_to
<%= button_to('Confirm order', action: 'confirm_order') %>
Затем в своем действии confirm_order вы можете перенаправить на сайт оплаты в отличие от размещения всей этой конфиденциальной информации на странице все время. Если кто-то наблюдает за сетевым трафиком, он увидит, что он проходит в заголовке очень быстро, но его не так просто найти и ссылку на странице, которую вы можете открыть в новой вкладке несколько раз.
def confirm_order
#Here I group all the parameters I'll need
@payment_params = []
description = "create_"+ @order.name.gsub(' ','_')
device_info = "WEB"
currency = @order.currency
fee = @order.price
#this was to concatenate the url, previouly I had the name of each parameter and the "&" taken into account, the response was different as I added each.
@payment_params << description << device_info << currency << fee
redirect_to("https://payexample/something/order?#{@payment_params}")
end
Я не совсем уверен, что вы хотите, чтобы этот URL перенаправления был. Это зависит от внешнего сайта. Если вам нужны параметры строки запроса, вы можете создать хеш ключей и значений и использовать метод to_query, чтобы превратить его в строку запроса.