[lyn)(browser]

Привет.
Есть несколько интернет-магазинов на разных системах. Нужно собрать данные корзины в виде json и отправить их к себе на сервер. При этом код сайтов-магазинов изменяем по самому миниму. /Клиент устанавляет на свой сайт то что мы ему даём - js-скрипт и т.п. Думаю, придется ограничиться им / Но мне кажется, что парсить код корзины на страницы как-то совсем глуповато.
Скажите пожалуйста, кто что думает.

@темы: Ajax, JavaScript, PHP

Comments

[Darsi :-)]

Аяксом экшены корзины.

[lyn)(browser]

Darsi :-), можно подробнее немного?
Там вся корзина должна отправляться по нажатию кнопки - по желанию пользователя.

[Скептичный циник]

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

[lyn)(browser]

Скептичный циник, Пока ничего не делали, ищу решение
Я не соображу , как именно эту инфу собрать. Сервер у клиента трогать нельзя, скорее всего.
У клиентов разные магазины Open Cart , Drupal Commerce - что угодно, сайты уже готовые. Пожелания : "Необходима минимальная модификация страниц заказов этих Интернет-магазинов".

[Скептичный циник]

lyn)(browser, индивидуально, руками, определяя магазин по ходу дела (или отдавая по уникальному скрипту на магазин). Повесить обработчик на нужную кнопку типа "купить", руками спарсить нужные данные с сайта и отправлять себе ajax. Для каждого типа магазина, соответственно, повторять шаги заново, если, конечно, они отличаются друг от друга. Достаточно знания/гугления javasсript, dom traversing, ajax и crossdomain.

[lyn)(browser]

Скептичный циник, ну так получается, я могу только из хтмл получить эту корзину в итоге, что-то меня смущает
все остальное представляю

[Скептичный циник]

Если магазин размещает ваш js у себя, то есть доступ к вёрстке, к клиентскому js-приложению и к api сервера.
Соответственно, вы можете посылать запросы из своего жабоскрипта к серверу магазина и получать инфу оттуда или вешаться на события js-фреймворка, например.
Всё-равно для каждого магазина придётся писать уникальный скрипт, если, конечно, эти магазины не конвеером наштампованы.

[lyn)(browser]

Скептичный циник, А как я из js достану api например, Open Cart? Мне этого как раз и хочется, потому что получать данные из верстки - это какая-то жесть на мой взгляд.
Но тогда мне должна выдаваться инфа ( в json или тп.) по некоему url-у на сервере клиента. А кто подготовит этот адрес и данные для запроса , если серверную часть клиента я не трогаю
/правда, у меня опыта с этим немного, могу ступить/

[Скептичный циник]

> А как я из js достану api например, Open Cart?
Понятия не имею, не работал с этой cms. Идёте на офсайт и курите документацию. Хотя я бы просто потыкал в нужные кнопки и продебажил через network в devtools.
Если магазин добавит ваш js-скрипт себе, то ничто не мешает слать любые ajax-запросы в вашем скрипте к серверу магазина и получать инфу.
Как их конкретно сформировать – нужно смотреть по конкретному проекту ибо данные вещи достаточно уникальны чтобы без конкретного кода обсуждение скатывалось к гаданию по фото.

> кто подготовит этот адрес и данные для запроса , если серверную часть клиента я не трогаю
Магазин же как-то работает |=> у него уже есть js, который обращается к серверу и получает эти данные |=> на сервере уже всё готово. Вам остаётся методом курения документации/курения исходников/расспросов разработчиков/научного тыка/дебага/usw (подчеркнуть по вкусу) понять куда постучаться за данными.

[lyn)(browser]

Скептичный циник, дык там что-то вроде методов get_cart(). Я не знаю Open Cart, но везде примерно одинаково. Но сам сервер,всмысле сайт-магазин, выдает уже готовые страницы по доступным адресам, а не чистые данные, и сам результат get_cart() я получить не могу из js (
Но проанализировать, что где срабатывает по кнопкам ,попробую.
Возможно, все равно придется что-то положить клиенту на сервер. Самих CMS не так много разных должно быть.

[Скептичный циник]

Если всё-таки есть возможность положить что-то на сервер хоть один файл, то это значительно расширяет возможности и всё упрощает.
Например, скрипт, который по крону будет проверять заказы в БД и делать post cURL запрос на центральный сервер для отправки данных. Он может там работать совершенно отдельно от сайта и никак на него не влиять, никакого js.

[lyn)(browser]

Скептичный циник, да, хотя бы просто тянуть из БД ,что нужно, здесь даже api не надо касаться. Просто мне непонятно, насколько это правильный подход. хочется,что б совсем лажово не было
По крону - не. Там им надо,чтоб по нажатию кнопки юзер мог перейти на другой сайт с сохранением своей корзины. js выходит, должен знать как минимум, что за юзер сейчас зайствован.

[Скептичный циник]

> просто тянуть из БД
Нормальный способ доставания данных, куда уж лучше?

> по нажатию кнопки юзер мог перейти на другой сайт с сохранением своей корзины
Так это в корне другая задача. Поддомен? Или совсем другой?

[lyn)(browser]

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

[lyn)(browser]

Как задачу описали - юзер при оформлении заказа туда перебрасывается тоже

[Скептичный циник]

По-хорошему, должно быть так:
1. Этот сервис доставки имеет API для магазинов. В редакции "минимум и достаточн" состоит из всего одного-единственного скрипта-коллбека, на который магазины могут перенаправлять пользователя. Технически – просто обработчик определённого урла.
2. Когда магазин считает, что пользователь оформил заказ – перенаправляет его на указанный в API коллбек-скрипт на сервисе доставки (см. п.1). При этом, передаются любые необходимые данные (например, о пользователе, о заказе, о корзине и вообще с любыми данными). Технически в магазине может выглядеть как тупой заголовок header('Location: service.delivery.com/callback.php?foo=bar&baz=gsom'); с добавкой в GET нужных параметров для передачи данных.
3. Сервис доставки, получая на этот коллбек пользователя (технически, самый обычный get-запрос), парсит из get'а данные.
4. После обработки данных перенаправляет пользователя (опять же заголовок Location) на точку входа для дальнейшей бизнес-логики по доставке и прочему. Нужно для того, чтобы не мусорить пользователю в url. Очевидно, можно редиректить куда угодно, хоть обратно в магазин.
5. Не обязательный пункт. Чтобы вам в сервис не насрали мусорными запросами, нужно этот скрипт закрыть белым списком авторизованных магазинов. Минимум – специальный рандомно сгенерированный токен, который знают только сервис и магазин. В идеале уже всё изобретено до вас и легко гуглится по названию oAuth. Тонны готовых библиотек.

Как понятно из описания выше, магазину, который хочет подключиться, нужно добавить в нужный скрипт заказа формирование данных для вашего сервиса и передать клиенту Location-заголовок. Не смотря на то, что оно должно быть добавлено в недры магазина, само добавление феерически простое. Левый несвязанный скрипт на сервере тут не поможет. Из дополнительных плюсов: магазин сам решает когда пользователь совершил заказ (он лучше вас разбирается в логике их же магазина) и может добавить любые дополнительные данные о самом пользователе, которых на сайте можете и не найти.
Придумывать свой велосипед с парсингом html и прочей лабудой не стоит без совсем крайней необходимости. Серьёзно, не стоит – любое мелкое изменение на магазине сломает всю систему.

[lyn)(browser]

Скептичный циник, Да, с Location ,значит кроссдоменный ajax не нужен.

Не смотря на то, что оно должно быть добавлено в недры магазина, само добавление феерически простое. Левый несвязанный скрипт на сервере тут не поможет. Из дополнительных плюсов: магазин сам решает когда пользователь совершил заказ (он лучше вас разбирается в логике их же магазина) и может добавить любые дополнительные данные о самом пользователе, которых на сайте можете и не найти.

Вы имеете в виду, серверный скрипт, написаный для конкретного магазина?

[Скептичный циник]

> Вы имеете в виду, серверный скрипт, написаный для конкретного магазина?
Да.
Если точнее, несколько строк, написанные для конкретного магазина, которые надо добавить в определённое место этого магазина – туда, где проходят все нужные заказы. Это место может быть уникальным не только для разных cms, но и для разных версий одной и той же cms.
Причём, они будут делать только две простые вещи: формировать нужные данные для сервиса доставки и редиректить пользователя с ними на ваш коллбек-урл.

[lyn)(browser]

Скептичный циник, Спасибо, помогли прояснить.
Буду в эту сторону действовать.

Если точнее, несколько строк, написанные для конкретного магазина, которые надо добавить в определённое место этого магазина – туда, где проходят все нужные заказы. Это место может быть уникальным не только для разных cms, но и для разных версий одной и той же cms.

Т.е. владельцу магазина нужно будет дать указание, куда разместить скрипт , или это будут делать мои товарищи. остается придумать, как максимально упростить эту задачу.

[Скептичный циник]

Да. Лучше всех знают логику работы магазина те, кто его писали.
С вас магазину нужен url, на который направлять пользователя и какие параметры в get передавать.
С магазина – отправка пользователя с этими данными после оформления заказа. Если это будете делать вы, то, во-первых, вам нужен будет доступ к коду сайта, а, во-вторых, придётся разбираться как работает каждый конкретный магазин/cms.

[lyn)(browser]

С магазина – отправка пользователя с этими данными после оформления заказа. Если это будете делать вы, то, во-первых, вам нужен будет доступ к коду сайта, а, во-вторых, придётся разбираться как работает каждый конкретный магазин/cms.

Мне придется делать /ну если не сольюсь/. Кто делал магазины, тех уж нет. Но там стандартные cms, в основном. Можно глянуть бд., вкрайнем случае, где хранится корзина и как.

[lyn)(browser]

Скептичный циник,

ехнически в магазине может выглядеть как тупой заголовок header('Location: service.delivery.com/callback.php?foo=bar&baz=gsom'); с добавкой в GET нужных параметров для передачи данных.

что-то меня опять притормаживает )
А ничего, если столько данных передавать Get'ом?

[Скептичный циник]

Обычно, у HTTP GET лимит в 2000 символов, однако RFC, емнип, на это нет и оно может настраиваться на уровне сервера. Если исчерпываете этот лимит, то, видимо, делаете что-то не так – я не могу представить такой use case.
Если данных много, используйте base64/serialize. Что-то вроде:

// Imagine tons of stuff here, whoa!
$user = Users::findByPk(42);
// Minify and configure data
$get = [
    'user' => serialize(base64_encode($user->toArray())),
    'cart' => serialize(base64_encode($user->getCart()->toArray())),
];
// Redirect user
$uri = $this->di('delivery-api')->getUri();
$location = $uri . '?' . http_build_query($get);
header('Location : ' . $location);

Если есть секретная/чувствительная инфа, то можно делать ssl+post запрос из магазина в сервис с данными, получать в ответ токен, а потом юзверя перенаправлять на сервис только с токеном, протухающим при использовании:

// Imagine tons of stuff here, whoa!
$user = Users::findByPk(42);
// Send data to service
$data = [
    'user' => $user->toArray(),
    'cart' => $user->getCart()->toArray(),
];
$token = $this->di('delivery-api')->sendPost($data)['sometoken'];
$uri = $this->di('delivery-api')->getUri();
// Redirect user
$location = $uri . '?' . http_build_query(['sometoken' => $token]);
header('Location : ' . $location);

[lyn)(browser]

Скептичный циник, Спасибо!
прояснилось
Я не знаю пока насчет секретности, но если в безопасности плохо шаришь, то думаю, лучше заранее этот момент учесть

[Скептичный циник]

Базопасность апи – отдельная большая тема, там очень много времени можно проторчать (:
Если нет секретных данных, то не вижу смысла пилить оверхед – get+base64+serialize вполне сгодятся.
Если есть, то задача сводится кj второму моему примеру: во-первых, обеспечить защиту передачи данных между магазином и сервисом, а, во-вторых, перенаправить пользователя с уникальным идентификатором (который позволит сервису юзать ранее переданную инфу).