Подтвердить что ты не робот

Должен ли я делать расчеты денег в Javascript или как вызов AJAX?

Я создаю webapp используя JQuery, Stripes, Spring и JPA (Hibernate).

У меня есть страница, которая позволяет пользователям вводить ряд позиций заказа и каждый раз, когда onblur возникает в поле цены, у меня есть событие JQuery, связанное с полем, которое суммирует все поля цены (это промежуточный итог), рассчитывает 10% налог и добавляет налог на промежуточный итог. Я обновляю страницу, чтобы отобразить промежуточный итог, сумму налога и общую сумму.

Мой вопрос: должен ли я делать это вычисление в Javascript? Если да, то как я могу быть уверен, что округление и т.д. Работает правильно? Я немного беспокоюсь о проблемах с точностью.

Было бы лучше, если бы я сделал вызов Ajax для вычисления в Java?

Любые советы были бы замечательными!

4b9b3361

Ответ 1

Как правило, вам нужно измерить то, что важно для вашего приложения. Если это абсолютная точность, сделайте это как вызов AJAX, потому что могут быть округленные различия между браузерами, компьютерами и ОС.

Когда я разрабатывал сайт для компании, над которой работал, у меня была такая же проблема, однако нам удалось использовать часть javascript, используя умный поворот, используя только целую арифметику.

Поскольку мы имели дело с валютой с двумя цифрами, мы умножили все на 10 000 и выполнили расчеты. Округление до целого числа и деление на 10 000 усечение результата до двух знаков после запятой.

Это делает круглые поездки красиво и последовательно между браузером и сервером.

Ответ 2

В comp.lang.javascript часто задаваемые вопросы, Javascript использует IEEE-754 и поэтому имеет точность 15-16 цифр при выполнении плавающего математическая математика. Этого должно быть достаточно для денежных операций при условии, что вы используете то же самое округление в Javascript, что и на стороне сервера.

Но если вам нужно быть абсолютно уверенным, что он будет исправлен в любом браузере, вызов Ajax будет самым безопасным способом.

Ответ 3

Если вы принимаете заказы, я бы рекомендовал, чтобы вы всегда делали расчеты на стороне сервера, прежде чем подтверждать заказ, чтобы не допустить, чтобы кто-то злонамеренно исказил данные, отправляемые от клиента. Тем не менее, вы можете сделать динамическое обновление с использованием JavaScript с некоторым соответствующим образом сформулированным отказом от точности, а затем представить пользователю свой расчет на стороне сервера, прежде чем они подтвердят заказ.

Ответ 4

вы должны сделать это на стороне клиента (я полагаю, что у вас есть ваши валидаторы на стороне клиента), чтобы пользователь мог видеть общее (я бы не хотел, чтобы мы делали обратные вызовы на сервер, чтобы просто увидеть общее количество) и также делайте это на стороне сервера. Исключение значений из POST не было бы очень хорошей идеей, так как кто-то с HTTPProxy мог бы изменить эти значения, если вы выберете его из HTTP POST.

TamperIE инструмент для вмешательства HTTP GET и POST и sandbox, где вы можете играть с

Изменить: Да, вы можете выполнить расчет на сервере, выполнив вызов AJAX, но вам нужно будет подтвердить общее количество в любом случае (против количества товаров + налог), когда пользователь отправит заказ

Ответ 5

Javascript - не лучший язык для математики. Вы найдете некоторые математические выражения, которые являются истинными, но возвращают false в Javascript. Не помню их точно, но я узнал, когда однажды сделал калькулятор.

Вы можете узнать о хороших и плохих частях Javascript здесь: http://www.crockford.com/

Ответ 6

Вы должны использовать фоновый код, в вашем случае являющийся Java, для выполнения строгих вычислений, поскольку нет гарантии, что данные не будут подделываться конечным пользователем в их пользу. И как только вы отправили им подтверждение подделанной цены, вы, по сути, связаны условиями вашего договора купли-продажи, даже если вы знаете, что они подделали общую цену. Там нет простого способа доказать, что они повлияли на ваш код или вычисления, и в свою очередь будет не в порядке. Используйте back-end, вы полностью контролируете эту среду, любые ошибки или просчеты с этого угла можно обвинять прямо на вас.