Взаимодействие клиент-серверного приложения на C, сайта на PHP и стороннего сайта

Question

[Robotex]

Итак, действующие лица: сторонний сайт, который работает с нашим через API, наш сайт на PHP, серверное приложение на С и клиентское на С. Сторонний сайт должен запросить у нашего информацию, наш сайт передает данные в серверное приложение (с помощью функции exec или подобной), оно в свою очередь по сокетам подключается к клиентскому, скидывает ему открытые ключи для шифрования и запрашиваемые данные. Клиентское приложение просит пользователя ввести данные (например, вставить электронный ключ или приложить палец к сканеру отпечатков), затем шифрует их и отправляет на сервер. Затем сервер расшифровывает данные, обрабатывает и отправляет ответ на сторонний сайт (например, аутентифицирует пользователя).

Так вот, как это сделать наиболее прозрачно для пользователя и сайта, использующего наше API. Чтобы пользователь просто получил надпись на стороннем сайте с предложением выполнить какое-либо действие (все сторонние сайты буду проверены перед разрешением использовать API), выполнил его и получил сообщение о результате. Если взаимодействие между приложениями на С, еще более менее понятно, то вот цепочка сторонний сайт-наш сайт-серверное приложение выглядит туманно. Т.е. я могу пройти цепочку сторонний сайт-наш сайт-сервер-клиент-сервер, но вот как вернуть результат на сторонний сайт не могу понять.

Ответ, если можно с простейшим примером — например, сторонний сайт посылает число, клиент множитель, сервер умножает число и множитель и отправляет результат на сторонний сайт.

Ах да, как серверу узнать IP-адрес клиента для открытия сокета? Ведь пользователь может использовать прокси, при чем не один, и конечный IP знает только сторонний сайт, но никак не наш (особенно, если прокси еще и анонимный).

P.S. Это не стартап. Увидел на одном сайте по безопасности такую систему и стало любопытно как же оно работает. Ну и решил выбрать это темой для курсового по безопасности информационных систем.

Answer 1

[Дмитрий Гукетлев]

ответ кроется в понимании http протокола. Давайте по частям:

1) передача сторонний сайт — ваш сайт. Тут все просто, сайты написанные на php в общем случае взаимодействуют по http. Есть какие-то экзотические варианты с сокетами в php но по моему надо использовать инстурмент сообразно его предназначению. Итак к делу. Сторонний сайт делает на ваш сайт http запрос, предавая в post (или гет) необходимую информацию. Скорее всего защищая её передачей хэш суммы с некотрой известной только сайтам солью. Например так:
your-site.ru/api/setNumber?num=10

2) Передача ваш сайт-ваше серверное приложение. самая сложная часть. Секрет кроется в том, что возможности php по работе с хостовой системой очень ограничены. Не уверен что php сможет послать например сообщение другому процессу на серверной системе. Тут обмен может быть реализован например так: php запускает какую-нибудь микропрограмму с параметрами, которая передает программе-серверу информацию, например послав системное сообщение (это правда черевато проблемами безопасности, разрешать php запуск программ довольно опасно). Либо php пишет информацию в некотрую БД а программа-сервер постоянно эту БД просматривает на предмет наличия новой информации.

3) передача ваше серверное приложение — клиентское приложение пользователя. Тут снова все просто. Ваша ошибка только в том, что сервер, в общем случае, не может открыть до клиента сокет. Клиент может быть за натом, за прокси да и просто порты могут быть закрыты. Поэтому приложение клиента открывает сокет к серверу, авторизовывается, и держит его открытым (как аська или мэил агент. Или чем вы там пользуетесь :) ). При поступлении некой информации программа сервер шлет их по открытому уже соединению клиенту.

Теперь поехали назад:
1) клиентское приложение — серверное приложение
Уже обсуждалось. У нас есть открытый сокет, по нему и отправляем.

2) серверное приложение — ваш сайт.
А вот приложению отослать информацию вашему сайту очень просто, достаточно сделать из серверного приложения http запрос на ваш сайт.

3) ваш сайт — сторонний сайт
снова просто — http запрос из вашего php скрипта на на сторонний сайт

Обратите внимание, что если для передачи «туда» все элементы цепочки важны: сторонний сайт скорее всего может сделать только http запрос, значит нужен ваш сайт который его примет. Ваш сайт не сможет держать сокет и послать информацию в программу клиент — нужна ваша программа сервер. То при походе обратно можно смело исключать любой из пунктов: ваша программа сервер может сама, без помощи вашего сайта, сделать запрос на сторонний сайт. Больше того программа клиент сама может сделать запрос на сторонний сайт и вообще можно выкинуть из обратного пути вашу программу-сервер и ваш сайт. Естественно все это надо защищать шифрованием от чтения и солями от подделки. (как подумайте сами, все довольно просто :) )

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

Это если говорить о вашей схеме: в жизни скорее всего «ваш сайт» вообще не существует, а «программа сервер» имеет модуль апача или сама по себе слушает соответствующий порт и отвечает на http запросы. Чтобы исключить затык с передачей информации из php в программу сервер. Это место будет все время глючить. Т.к. php для этого банально не предназначен. А в случае реализации с опросом БД будет дополнительная задержка.

Comments

[Владимир Чернышев]

2) Передача ваш сайт-ваше серверное приложение. самая сложная часть.

Не думаю, серверное приложение скорее всего слушает какой-то сокет, на PHP создаём сокет (IPv4, IPv6, Unix), коннектимся к серверному и пишем/читаем в/из него согласно его протоколу. Если протокол синхронный, то никаких особых проблем нет: записали, ждём ответа, ответ пришёл, записали ещё что-то, ждём ответа, ответ пришёл последний — закрываем сокет отвечаем стороннему серверу.

P.S. Вообще PHP даёт почти полный контроль над nix хостом (естественно при установке соотвествующих расширений и наличии прав у процесса, убить init например только из под рута можно)

[Robotex]

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

[Владимир Чернышев]

Если сторонний сайт использует флэш, то фактически это не сайт, а клиентское приложение. Во флэше не силён, но думаю оно может не просто отправить запрос, но и дождаться ответа :) Если всё же необходимый для ответа время слишком большим будет, то да, периодический опрос: Сначала, например, посылаем запрос на создание объекта: GET /create_user?request_uid =1234567..., потом периодически шлём запрос создан ли объект: GET /user_created?request_uid =1234567… Это если в лоб, если более красиво хочется, то различные server push технологии.

Обычная практика — хранить признаки аутенфикации/авторизации в сессиях, если в течении какого-то времени клиент не подавал признаков жизни, то сессия удаляется и при следующем запросе ему нужно будет заново аутенфицироваться.

[Robotex]

Не понятно про постоянно открытое подключение. Есть сервер, к которому подключены несколько клиентов, сайт отправляет запрос авторизации и как серверу понят кого именно авторизовать? Прелесть в отпечатках/ключах в том, что они самодостаточны, не нужно никаких логинов. Но как в этой ситуации узнать какой именно пользователь?