Реализация доступа к сайту для запросов с определенных сайтов

Попробовал. За пример взял этот материал: http://i-novice[dot]net/sokety-v-php/
Сервер: (http://server)

Ага....яяясно
А что если на одной машине будет более одного сервера?
Ну например на одном хостинге вдруг два твоих клиента будет крутиться?
Хосты разные а железка одна
Как будет работать?

я же подключаюсь к сокет-серверам по имени домена а не по ip. Не вижу в этом проблемы.
Да и при чём тут "железка"?
(Добавление)
Может в следующем я буду не прав (в плане терминологии), но смысл должен быть понятен.
Связь между процессами будет 1 к 1.
1 процесс Сервера общается с 1 процессом Клиента.
Связь 1 ко многим исключена.

Но ведь на самом деле хост резолвится в ip и соединение происходит на ip
В http есть заголовок host и там все понятно
А если на одной железке откроются два сокета на один клиент и порт, то к какому клиент подконнектится
Мне вот непонятно
(Добавление)
Проверь а
Открой на одной машине но на разных хостах
(Добавление)
Откуда процесс на клиенте узнает с каким процессом ему коннектиться?

Проверил. Ну чтож, придётся по http коннектится.
Спасибо.

и как проявилось?

запустил сервер1. С клиента2 подключаюсь к сервер2 и тут на сервер1 приходит коннект.
(Добавление)
А вот если разные порты, то работает как надо.

Ну если к всем подключается то можно передавать уникальный токен запроса и каждый будет реагировать на свой ответ
Надо будет почитать сокеты внимательнее
(Добавление)
Ну порты это понятно
Только их не напасешься
(Добавление)
Или только к первому открытому конектит?

ага.
Можно и так, а можно и http
(Добавление)
с разными портами ок работает

Я понял, почему http мне не подходит. Ключ соединения же должен проверяться на сервере а не на клиенте.
В случае с http, нельзя проверить ключ на сервере, так как второй запрос делается с сервера и в нём должны передаваться запрошенные данные.
В случае с сокетами всё проще, сервер коннектится к клиенту, клиент посылает ключ, сервер проверяет и принимает меры.
(Добавление)
Да уж, с сокетами возникает та же проблема, только вид сбоку.

Можно и с http если отправлять асинхронно
Например устанавливается авторизация
Клиент отправляет запрос в котором есть uri куда отправлять данные ну и токен запроса
Сервис отправляет данные проверив и домен конечно
Принявший данные скрипт например кладет ответ в бд с токеном
Запросивший скрипт опрашивает периодически бд на предмет ответа
вот такой костыль
(Добавление)
Хотя все это конечно полнейшая фигня
Проверять домен при авторизации и хорош

Привет коллеги! Лайм и Био.
А я все в скайпе пишу и пишу, а тут такая тема
Лайм прав на счет продажи пакетов. Только продавать надо не кол-во коннектов, а количество СМС, которые будут приходить к юзеру при запросе восстановления пароля и по расписанию для перекрестной проверки, а также при обновлениях.
А чтобы заморочить голову честным тырильщикам, нужно увеличить кол-во идентификационных данных и абфусцировать ключ активации своим абфускатором с ключем.

Что у нас есть в итоге:
1. ФИО (обязательно)
2. почта (обязательно)
3. мобила (обязательно)
4. уникальный id системы (обязательно)
5. IP адрес сервера
6. доменное имя
7. файловый ключ 2, который проверяет контрольное число при перемножении с другими данными.

И нужен биллинг сервер на котором будут храниться ключи и собираться данные логов апдейтов разных id системы.

Таким образом тырильщики не получат обновлений системы никак и им придется постараться чтобы выковырить все проверки.

В реализации механизма с сокетами боюсь что хостинг сервера могут не разрешить такой вид проверки.

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

Самое лучшее имхо в систему встроить API которое будет раз в день при заходе в админку обновлять информацию о сроке использования ключа, времени регистрации домена и сроке предоставления хостинга, данные должны вбиваться в БД на сервере с лицензиями и обновляться для пользователя (и удобно, и полезно, и мы в курсе). А на самом сервере сделать систему аналитики использования разных id системы.

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

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

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

Всё это, конечно, ценные мысли, но вопрос в том, как максимально безопасно передать данные клиенту.
Вот, набросал ещё 1 схему.

Достоинства:
1. Минимум запросов.
2. При хищении ключа, данные всё равно придут на нужный домен, а там уже будут решать, их это данные или кто-то от их имени делал запрос.
3. Что-то ещё?

Недостатки:
1. Пока не вижу, может завтра увижу косяки.


Схема открыта для обсуждений, пишите свои мысли.
P.S. Не обращайте внимание на нумерацию, программа сама понаставила.
Прикреплено изображение (Нажмите для увеличения)

Bio man а что будет если аякс запрос не пройдет по каким либо причинам или будет банально отключен в коде?

iddqd
1. Зачем его отключать в коде? Вся админка будет одностраничной, построенная на emberjs или подобном фреймворке.
2. Если не пройдёт, то выведется сообщение об ошибке, это же не сложно отследить.

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