Ну например на одном хостинге вдруг два твоих клиента будет крутиться?
я же подключаюсь к сокет-серверам по имени домена а не по ip. Не вижу в этом проблемы.
Да и при чём тут "железка"? (Добавление)
Может в следующем я буду не прав (в плане терминологии), но смысл должен быть понятен.
Связь между процессами будет 1 к 1.
1 процесс Сервера общается с 1 процессом Клиента.
Связь 1 ко многим исключена.
Create socket ... OK
Bind socket ... OK
Listen socket ... OK
Accept socket ... OK
Say to client (Hello, Client!) ... OK
Client said: Hello, Server!
Say to client (Hello, Server!) ... OK
Client said: shutdown
Close socket ... OK
Address: server
Port: 10001
Create socket ... OK
Connect socket ... OK
Server said: Hello, Client!
Say to server (Hello, Server!) ...OK
Server said: Hello, Server!
Say to server (shutdown) ... OK
Close socket ... OK
а как ты сможешь ответить на tcp-сокет от клиента?
А как обычно делают общение между сокетами? На том же php.net есть примеры реализации общения клиента и сервера. В моём случае у клиента будет запущен сокет-сервер, а центральный подключится к нему как клиент.
Ну обычные tcp сокеты и имелись ввиду )) Клиент это не браузер а система на клиентском домене. То есть предполагалась связь "сервер клиента"-"центральный сервер".
До "сделаешь" ещё много месяцев, пока нужно придумать, обдумать, написать, нарисовать. А потом уже делать.
И кстати зачем сокет? Почему просто клиент не может передать адрес на который ему надо отправить запрошенные данные
Первый запрос от клиента идёт по http, где клиент сообщает ключ аутентификации и доменное имя. Сервер в ответе высылает ключ ConnectionKey.
Сразу после получения ответа, клиент создает сокет-сервер и ждёт подключения от сервера.
Сервер подключается по переданному домену из первого запроса.
Если запрос делал левый сайт и передал правый домен, то сервер не сможет подключится, так как там не ждут подключения сервера.
Если всё же сокет-сервер на клиенте и создан, то сравниваются ConnectionKey, что бы определить, действительно ли он делал запрос.
Хотя да, можно просто посылать http запрос с запрошенными данными... В общем, не важно, сокет это или http, принцип один. (Добавление)
LIME пишет:
Я имею ввиду давать клиенту 10 000 запросов в месяц - тариф базовый!
И пусть авторизуется хоть с сотни доменов
Оплачивается объем
Предоставляются логи
При 9 000ном запросе высылается предупреждение
Ну и всетакое
Предложу твой вариант начальству )) но врятле он с тобой согласится
И как это помешает мне организовать свой шлюз к твоему сервису?
и не просто все свои проекты к тебе направлять а и вообще торговать твоими услугами налево))
Видимо никак. К сожалению, никакой способ этому не помешает.
Конечно, я не совсем понял что ты имеешь ввиду, но в данной схеме обрубается доступ с левых доменов, в том числе с левых доменов выдающих себя за правый домен.
Но всё это можно обойти перенаправив полученную информацию с клиента на левые домены (сайты), и никакая защита на сервере уже не защитит, так как обращения к нему происходят только с правого клиента, левые туда даже не лезут, так как бесполезно им туда лыкаться. (Добавление)
В отличии от этой http://forum.php.su/topic.php?fo...10881#1432410881 схемы, доступ будет иметь только аутентифицированый клиент, левым в доступе будет отказано.
Вроде придумал вариант, где злоумышленник не сможет получить прямого доступа к API сервера.
Суть в том, что в ответ на "рукопожатие" сервер высылает ключ доступа, клиент его сохраняет и запускает сокет-сервер.
Сервер коннектится, как сокет-клиент к клиенту по переданному в первом запросе домену.
Если коннекта нет или ключи не совпадают, значит запрос делал не клиент.
Если же всё хорошо, сервер шлёт запрашиваемую информацию и закрывает соединение.
Никак. Если файл отдаётся через скрипт то никак. А если и каким то образом узнать, то скорее всего папка с ресурсами будет закрыта для внешнего доступа (это если она в пределах webroot, если за ней - то и URL адреса даже не получится).
Короче никак.
Я так понимаю, нужна проверка, что запрос пришел именно от такого-то ip и такого-то домена, тогда можно сделать так.
Хорошая идея но есть 1 НО:
Если злоумышленник приобрёл "ключ аутентификации" и захотел его использовать на нескольких копиях продукта, то модифицировав код "аутентифицированной" системы сможет обойти вышепредложенную защиту.
Вроде понятно отобразил идею обхода на диагараме последовательности. Прикрепил картинку. (Добавление)
Какие соображения по этому поводу?