Баг или уязвимость в заказах

[nuki]

Опишу вкратце ситуацию:
Если зарегистрированный пользователь делает заказ, то в итоге его заказ доступен по ссылке домен/order/1c9d78dc4f72d5a5c560932b45b5436e - но перейти по этой ссылке и увидеть подробности заказа и информацию о пользователе может любой человек. Впрочем случайно попасть туда невозможно, только если кто-то сознательно скажет ссылку своего заказа. Проблема в другом - пройдя по этой ссылке совершенно любой человек может нажать кнопку "выбрать другой способ оплаты" и это изменение сохраниться. Это уже не очень хорошо.

[Гость]

Вы предлагаете сделать регистрацию обязательной?

[nuki]

Нет конечно, я наверное непонятно объяснил. Суть проблемы в том что зная ид заказа (1c9d78dc4f72d5a5c560932b45b5436e) любой человек без регистрации может изменить в чужом заказе способ оплаты.
Или это я что-то не понимаю, может и такое быть)

[Гость]

Да, но этот код знает только тот кто заказал.
Я к сожалению пока не придумал как сделать так, чтобы в заказ мог зайти только тот кто его сделал. Можно конечно ставить куки, но ведь покупатель не обязательно будет заходить из того же браузера, с которого сделал заказ. Запомнить ip - та же проблема

[anton]

Не вижу ничего криминального.

[nuki]

Куки это определенно не выход. Может быть выходом было бы использование одноразового пароля? Человек при формировании заказа получает не только эту ссылку, но и одноразовый пароль, как капча, YP4K или 674E, не сложнее. И только подтвердив свою принадлежность к заказу - получает возможность видеть его статус или изменить способ оплаты. Т.е. пароль привязывается к заказу - заказ выполнен - пароль удалился. Не думаю что это бы слишком усложнило систему.

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

2anton, криминала нет, если человек спалил кому-то ид своего заказа - сам виноват.

[dolphin]

лучше емайл использовать как пароль
а удалять заказы не надо
угадать ид + емайл мало шансов

[Kpoxa]

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

[dolphin]

а что изменится если человек изменил способ оплаты ?

видимо нужно давать изменять заказ пока статус заявки не закрыта, если админ сделал заявку "закрыть" то все, изменить нельзя, хотя можно дать админу право ее открыть мало ли

[Гость]

> Я вот не понимаю для чего дана возможность изменять способ оплаты после того когда заказ оформлен.
Иногда может не получиться оплатить выбранным способом, тогда покупатель попробует оплатить другим

[Kpoxa]

Тогда у человека может быть возникнуть необходимость поменять адрес доставки, все возможно...
А вот идея на счет того, чтоб можно менять заказ до того момента пока он в обработке, думаю что стоящая.
Как только он перешел из разряда "Новый", то нужно блокировать редактирование, это мое мнение и не обязательно, что оно верное.

[Kosjak76]

Ну так поставте в шаблоне проверку по статусу заказа, при таких статусах показывать выбор, при других - нет

[Гость]

> Тогда у человека может быть возникнуть необходимость поменять адрес доставки, все возможно...
Ну если так рассуждать, то может он захочет поменять и заказанные товары?
Если заказ сформирован, то поменять без звонка менеджеру ничего уже нельзя, и я думаю что это логично.

Вот только как это касается оплаты существующего заказа?

[Гость]

Kpoxa, мне кажется вы смешиваете понятия заказа и оплаты этого заказа. А это разные вещи. Заказ он вот есть, тикие-то товары, доставка туда-то.

А оплата этого заказа - это уже отдельная процедура.

[Kpoxa]

Я представляю как
Выбранные Товары отгружаемые Кому-то, доставляемые Куда-то и оплаченные Как-то.
Вы же отделяете оплату от заказа, Ваше право. Вы автор Вам и решать как сделать.

[dolphin]

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

[Kpoxa]

Спасибо, дошло

[Rendalina]

Могу сказать с точки зрения клиента. Недавно решила поменять в согласованном заказе способ оплаты с банковского перевода на оплату пластиковой картой. Так вот - не смогла. Пришлось звонить в банк, потом в магазин, ждать. В итоге из магазина перезвонили и сказали перезаказать товары с новым способом оплаты, а старый заказ отменить.
Хотя сам магазин очень приятный и продуманный.

В общем, лучше пусть будет возможность изменять способ оплаты в заказе.
Ну не пришли мне деньги на одну карту - оплачу другой, схожу в банк наличку закину, через платежный терминал какой-нибудь электронной валютой закину. Или возникли непредвиденные траты, хочется чтобы наложкой отправили, а не по предоплате. Всё равно посылка две недели будет идти, я за это время зарплату получу. Ну переплачу немного почте, это лучше, чем деньги занимать, чтобы прямо сейчас оплатить. Почему я из-за этого должна звонить в магазин, объяснять ситуацию и просить менеджера?
А всякие доп.пароли - это только лишние неудобства. Причем для ВСЕХ клиентов. Вы еще обязательную регистрацию сделайте.

ИМХО, если так боитесь, то лучше тогда хранить историю способа оплаты.
Видите, что способ оплаты поменялся - засомневались - звоните клиенту и уточняете, как ему удобнее оплачивать. Или поступления денег ждете, смотря что на что поменяли.

[Ivan923]

Версии 2.0 можно сделать так отображение для вошедшего под e-maill и паролем т.е. если пользователь не авторизовался можно сделать корзине что он не может заказать, закрыть кнопку заказа таким кодом
<!-- Вход пользователя -->
{if $user}

{/if}
вот находим кнопку в файле cart.tpl:
{if $user}
<input type="submit" name="checkout" class="button_submit" value="Оформить заказ">{/if}

в файле order.tpl тоже можно закрыть если не авторизован часть заказа информации :
Пример кода
<h1>Ваш заказ №{$order->id}
{if $user}(<---это мы вставили){if $order->paid == 1}оплачен{else}еще не оплачен{/if},
{if $order->status == 0}ждет обработки{elseif $order->status == 1}в обработке{elseif $order->status == 2}выполнен{/if}
</h1>

и в конец файла ставим {/if}


P.s. Информация конфиденциальность останется но посетителю необходимо регистрироваться в вашем интернет-магазине, проверял сам лично заказ по ссылки /order/ce521705cc587c14a31f7c33d8b122b0 мне как гостю сайта не доступно кроме номера заказа. В корзине скрыл кнопку на оформление заказа.

[Rendalina]

Ivan923, для полноты картины хотелось бы видеть статистику ухода со страницы заказа до вашего нововведения и после )

[Ivan923]

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

[fonetic]

Главное чтобы эти ссылки были закрыты от индексации, а то получится как у webasyst. Они добавили проверку на фамилию потом.

[tbox24]

Ого интересная темка .
Надо будет попробивать протесить на своем маге.

[tbox24]

Главное чтобы эти ссылки были закрыты от индексации, а то получится как у webasyst. Они добавили проверку на фамилию потом.
Тупо как то .

[Rotveller]

Эта проблема решается достаточно легко для зарегистрированных пользователей.

 

В шаблоне order.tpl нужно просто подставить проверку на соответствие id текущего пользователя и id пользователя, сделавшего заказ.

 

Код:

 

{if $order->user_id == $user->id or $order->user_id==0}  //второе условие для случая с незарегистрированным

// Здесь код шаблона...

{else}

У вас нет доступа к этой странице

{/if}