1 (изменено: Botsy, 2020-11-20 16:07:14)

Тема: AHK: Схема клиент-сервер от мульти использования

Доброго всем. Как вы думаете, такая схема отношений клиент-сервер реализуемая и нормальная или лучше сделать что-то по другому ? Задача ограничить скрипт от мульти использования.

+ открыть спойлер

Алгоритм:
- после запуска скрипта, окно с вводом ключа (KEY)
- скрипт обращается к файлу (txt) на сервере
* получает содержимое файла в переменную
* ищет введенный клиентом ключ
* если ключа нет, выход из скрипта
- получает SID клиента
- обращается на сервер к файлу (htm)
* если у ключа пустое поле SID, привязывает SID к введенному ключу и записывает результат
* получает значение SID у ключа
- если SID клиента не совпадает с полученным SID от ключа из файла htm, выход

https://i.ibb.co/LQgBWV8/sheme.jpg

UPD: новая схема в сообщении "39"

GD

2

Re: AHK: Схема клиент-сервер от мульти использования

Хорошее начало, только всё сумбурно и непонятно где что на картинке. Уж лучше описать словами по порядочку: откуда чего берётся, кто у кого скачивает, кто у кого проверяет и т. д.

3

Re: AHK: Схема клиент-сервер от мульти использования

ypppu Вот так более понятно ?
- При запуске скрипта, вводим ключ (KEY).
- Скрипт обращается на сервер к файлу (txt), парсит его.
- Сравнивает введенный ключ с ключами в файле. Если ключа нет, выход из скрипта. Если ключ есть, идем дальше.
- Получаем SID клиента. Дальше обращаемся на сервер к файлу (htm), парсим его.
- Если у ключа пустое поле SID, привязывает SID клиента к введенному ключу и записывает результат в файл htm. Если у ключа не пустое поле SID, то копирует его значение.
- Дальше идет проверка скопированного SID из файла htm, с SID клиента, который запустил скрипт. Если SID клиента не совпадает с полученным SID из файла htm, выход.

Файл txt


key[1] = 44
key[2] = 45
key[3] = 46

Файл htm


key[1] = 44 = SID.85969658547
key[2] = 45 = ""
key[3] = 46 = SID.12456758425

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

GD

4

Re: AHK: Схема клиент-сервер от мульти использования

Получаем SID клиента - кто получает SID клиента? Сервер?

5

Re: AHK: Схема клиент-сервер от мульти использования

ypppu Скрипт локально получает SID и записывает его в переменную, а потом уже передаёт на сервер.

GD

6

Re: AHK: Схема клиент-сервер от мульти использования

- При запуске скрипта, вводим ключ (KEY). При первом запуске или при каждом запуске?
- Скрипт обращается на сервер к файлу (txt), парсит его. Здесь вроде понятно. Скрипт скачивает файл с сервера. Затем скрипт парсит этот файл.
- Сравнивает введенный ключ с ключами в файле. Это что же получается, перечень ключей хранится на сервере в открытом виде? Просто как текстовый документ? Наверное всё же следует его поместить в какой-нибудь зашифрованный архив.
Дальше вообще мало что понял.

7

Re: AHK: Схема клиент-сервер от мульти использования

Почему бы на сервере всё и не парсить? Скачивать оттуда все эти списки, по-моему, плохая идея.

8

Re: AHK: Схема клиент-сервер от мульти использования

Ну, когда в веб-программировании особо не шаришь, плюс в качестве сервера используется какой-нибудь narod.ru, тогда проще парсить на клиентской стороне. Администратор заливает файл, зашифрованный средствами Autohotkey, на хостинг. А клиентский скрипт скачивает его и расшифровывает. А как работает дешифратор - пользователь не узнает, если использовать AutoHotkey 1.0.48.05. Однако, такой подход не позволяет контролировать кол.-во одновременно работающих клиентских скриптов. Нужно или шарить в веб-программировании, или 100500 пользователей смогут запускать программу с одним и тем же ключом.

9

Re: AHK: Схема клиент-сервер от мульти использования

ypppu Как на сервере хранить зашифрованный файл с ключами, ещё не знаю. Можно парсить его с сервера через winhttp в строку, а результат уже сравнивать поиском по строке.
100500 пользователей не смогут пользоваться по одному ключу, так как ключ будет привязан к Sid клиенту, при его первом запуске. На бумаге вроде выглядит логично.

GD

10

Re: AHK: Схема клиент-сервер от мульти использования

При первом запуске скрипт скачивает файлик, в котором имеется список свободных ключей? Или сам генерирует ключ? В конечном итоге: администратор должен иметь на руках список SID и список соответствующих ключей или задумывается так, что это всё будет происходить как-то без его участия?

11

Re: AHK: Схема клиент-сервер от мульти использования

ypppu

Вроде всё понятно.
Пользователь скачивает программу и запускает, прога создаёт уникальный для его текущего компа 'ключ' ('SID' и/или ещё что-то) и сверяет его наличие в списке на сервере. Если доступ закрыт (т.к. его ещё нет в списке, пользователь новый) программа предложит отправить шифрованный 'ключ' автору программы - Botsy. Через некоторое время пользователь вновь запускает программу. Она сверяет обновлённый список на сервере, разрешает допуск к основным функциям и работает как задумано - полнофункционально.

12

Re: AHK: Схема клиент-сервер от мульти использования

Вообще логично. Но это ручная работа для Botsy. Стало быть нужно, чтобы у него было свободное время ровно тогда, когда пользователю заблагорассудится устанавливать программу. Или же пользователю придётся ждать, пока Botsy освободится от своих личных дел.

13

Re: AHK: Схема клиент-сервер от мульти использования

А как иначе такое осуществить? У нас нет своих работников, которые 24/7 принимают запросы. Если только как-то научить скрипт отправлять запрос на сервер, который организует добавление в шифрованный список нового 'ключа'.

14

Re: AHK: Схема клиент-сервер от мульти использования

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

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

GD

15

Re: AHK: Схема клиент-сервер от мульти использования

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

16

Re: AHK: Схема клиент-сервер от мульти использования

Botsy

Мне бы такую программу, которая всё делает за меня и только то, что мне нужно!

Если все пользователи сами будут добавлять данные при запуске программы - то где смысл защиты? Зачем тогда сервер с списком разрешённых?

17

Re: AHK: Схема клиент-сервер от мульти использования

__Михаил__ Сами клиенты ничего добавлять не будут, а вот скрипт которым они пользуются - да.
Представьте если скрипт запустил человек_1 и человек_2 одновременно. Оба скрипта парсят файл (htm) на сервере, оба скрипта вносят в файл информацию и сохраняют его. Разве не будет конфликта на сервере, если несколько подключений одновременно будут вносить изменения в один файл ?

GD

18

Re: AHK: Схема клиент-сервер от мульти использования

Botsy

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

19

Re: AHK: Схема клиент-сервер от мульти использования

__Михаил__ Вот, как раз для таких коррекций я и создал эту тему. Обсудить схему в целом на предмет логичного и реализуемого алгоритма.
Догадывался что не получиться редактировать один и тот же файл одновременно разными подключениями, поэтому и предложил вариант хранить инфу в БД. А способ получать из неё информацию, менять и сохранять ее одновременно разными подключениями сделать через sql или типо того.

GD

20

Re: AHK: Схема клиент-сервер от мульти использования

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

21

Re: AHK: Схема клиент-сервер от мульти использования

Серверы с Windows - дорогое удовольствие. За то Линуксовые можно найти (за копейки, от ~50р в месяцхабр-обзор для ориентира). Развернуть там например, Nginx + PHP + MySQL = решение, готовое обрабатывать около 1 - 2 тысяч запросов в секунду на процессорное ядро, даже с кривыми руками. Статей, описывающих пошагово как это сделать очень много. Можно даже хостинг для сайта взять и на его платформе что-то клеить, но там свои подводные камни.

Можно так же минуя всё, написать собственное, асинхронное решение на Python 3.5+. Это потребует понимания многих тонкостей работы сервера, но за то из сборки aiohttp + uvloop, такой Линукс будет выдавать на порядок большую производительность. Будет надёжнее и работать глаже, если ожидаете большой трафик и обращение к БД. Хотя Nginx всё равно будет желателен.

По простому, полностью автономной задачу можно решить следующим способом:
Регистрируетесь, например, в Yandex(хотя, теперь уже Yoo)-money, можно и QIWI. У них есть удобное и хорошо документированное API, связку с которым Вы описываете в примитивном HTML-шаблоне, который вместо приветствия будет выдавать Ваш сервер. Можно даже не регистрировать доменное имя. На страницу можно и по выданному провайдером IP-адресу попасть.
На нём должна быть форма со всего одним инпутом, в который пользователь пишет свой почтовый ящик. Дальше, по нажатию кнопки "Отправить", запоминаете его почту и снабдив внутренним идентификатором Вашего сервиса, выполняете редирект запроса в платёжную систему. Там она сама разбирается с ним и если он всё правильно заполнил и оплатил, то вашему сервису, через веб-хук прилетит уведомление с тем самым, внутренним идентификатором, по которому Вы опознаете плательщика.
Генерируете в таблице ключей для Вашего софта, новый, уникальный хэш с датой его создания и отправляете его на указанную почту.

Далее, описываете некий resolve-API, которое будет выдавать оценку прилетающим запросам от пользователей софта, который будет стрелять в него введёнными ключами из почты и проверять как валидность самого ключа, так и его актуальность(просрочен/годен). Соответственно, на выданный ответ, софт будет либо работать, либо...

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

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

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

22 (изменено: svoboden, 2020-11-16 00:12:32)

Re: AHK: Схема клиент-сервер от мульти использования

А зачем sid клиента? При привязки нужен hwid компьютера. Я уже давно свою программу на ++ переписал, т.к. там есть библиотека Boost.Asio, там и запросы шифруются и по скорости не сравнить с ахк.  А в качестве сервера выбрал бесплатный pastebin, там и хранятся ключи авторизации.

23

Re: AHK: Схема клиент-сервер от мульти использования

KusochekDobra Спасибо за такой развернутый ответ. Интересная альтернатива с авто оплатой, в реализации конечно сложнее моего полуавтоматического способа.
Мне больше понравилась идея с php + mysql, это можно сделать и не на линуксе и что еще важно, это вроде должно норм вписаться в схему из 1-ого сообщения. Т.к. ваш вариант, который полностью автоматический с оплатой, я скорее всего не смогу сделать сам.

GD

24 (изменено: Botsy, 2020-11-16 00:12:10)

Re: AHK: Схема клиент-сервер от мульти использования

svoboden Теоретически в будущем, есть смысл перевести на другой не скриптовый язык, а пока общую концепцию можно и на ахк сделать).
SID намного надёжнее чем HWID.

GD

25

Re: AHK: Схема клиент-сервер от мульти использования

Всякого рода авторизации клиентов, на стороне клиента — это ОЧЕНЬ плохая практика, нивелирующая весь смысл, для которого всё и делается.

У Вас, в "удалённом месте" расположено два оперируемых объекта выполняющих одинаковую роль, от чего смысл первого теряется. Первый только для "чтения", а второй для "чтения|записи". Допустим, в "удалённом месте" вы можете настроить права доступа к ним именно так, но вместе с этим, оба доступны извне. При этом, имея права Вашего сценария(о которых Вы конечно же тоже позаботитесь) — второй можно удалённо изменять.

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

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

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

"И так сойдёт" — работает только для любого Вашего, частного случая. Когда речь заходит о том, что Вашей поделкой будет пользоваться кто-то ещё, нужно учитывать все вероятности, а их, поверьте — совсем не чуть-чуть.

26

Re: AHK: Схема клиент-сервер от мульти использования

KusochekDobra Хорошо, а если так:?
- есть демо версия скрипта (при запуске скрипт получил SID и хранит его в переменной)
- клиент жмет на кнопку с покупкой полной версии
- открывается браузер с нужной страницей. Там инпут, скрипт автоматом вставляет туда значение с переменной SID. Вместе с инпутом есть кнопка, предлагающая продолжить.
- если нажать на кнопку, сервер передаст данные из инпута в БД, а так же создаст и запишет для него уникальный ключ. После покажет этот ключ пользователю в браузере. (в БД сохранится запись его SID и его ключа. Если он закроет страницу или попробует в другой раз сделать тоже самое, то сервер будет выдавать ему один и тот же ключ для его SID из БД)
- этот ключ ему надо будет скопировать и скинуть в телеграм-бот.
- телеграм-бот сопроводит его для дальнейшей оплаты
- после всего, компилируется полная версия программы индивидуально под его ключ и SID.
- телеграм-бот скидывает ссылку на скачивание программы.

Получается дальше можно будет точечно проверять связь ключа и SID на сервере, не выдавая данных других клиентов. Что думаете ?

GD

27

Re: AHK: Схема клиент-сервер от мульти использования

А если он купил программу, а потом выкинул старый компьютер и купил новый? SID изменился. Заново ключ покупать?

28 (изменено: KusochekDobra, 2020-11-17 19:48:03)

Re: AHK: Схема клиент-сервер от мульти использования

Botsy, видно, что вы себе всё плохо представляете, как оно работает.

Пункт с браузером можно пропустить. Если пользователь собрался сделать приобретение и есть ещё что-то, что следует уточнить, на месте проводите опрос стандартными диалогами вроде InputBox, или MsgBox, результат которого отправляете POST-запросом на адрес API Вашего web-сервиса. Там его разбираете, делаете все манипуляции и отправляете обратно результат. Результат этот можно для верности сохранить в текстовый файл по месту запуска сценария, а так же продублировать в буфер, о чём сообщить пользователю.

Остальное по сценарию с пятого пункта.

Думаю, Вам надо ещё ко многому приобщиться.

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

29 (изменено: Botsy, 2020-11-17 21:05:20)

Re: AHK: Схема клиент-сервер от мульти использования

Это да, паззл еще не сложился.

Примерно правильный алгоритм для начала?
- в скрипте обрабатываю первичную информацию
- потом при помощи "ComObjCreate("WinHTTP.WinHTTPRequest.5.1")" посылаю ее на страницу сервера
- на странице ловлю ее при помощи php
- дальше при помощи php взаимодействую с sql
- потом опять через php посылаю обработанную информацию на страницу
- забираю информацию со страницы в скрипт опять при помощи "ComObjCreate("WinHTTP.WinHTTPRequest.5.1")"

GD

30

Re: AHK: Схема клиент-сервер от мульти использования

В целом да, но кое что требует уточнения:
Вы общаетесь скриптом напрямую с сервером. Нет никаких страниц. Когда выполняется запрос, адресом которого указан "http://домен/имя" — сервер запустит интерпретатор PHP и выполнит лежащий в корневой директории сценарий "имя.php" передав ему в качестве окружения всё содержимое запроса, которое можно получить из глобальных переменных. Соответственно, внутри такого сценария Вам нужно описать свою логику выполняющую генерацию нужных данных, какие-либо действия с БД и например, отправить через "echo" ответ, его то и получит сценарий на свой POST-запрос.

31

Re: AHK: Схема клиент-сервер от мульти использования

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

KusochekDobra, договариваться - ручная работа. А если заранее известно, что у пользователя будет включен интернет, почему бы не вшить ключ в скрипт? Эдакий CD-key.

32

Re: AHK: Схема клиент-сервер от мульти использования

Раз пошла такая малина, можно и авторизацию через личный кабинет замутить. Тогда вообще всё будет делегировано в руки пользователя. Сам сломал свой комп, сам же зашёл в ЛК, сбросил старую сессию, выписал себе новый ключ. Можно себе компьютер по КД ломать.

33

Re: AHK: Схема клиент-сервер от мульти использования

Сессия, по моему представлению, должна сама сбрасываться по таймауту (например 5 минут). Но это уже совсем другая история. Выписывать себе ключ не надо. Он находится внутри скрипта в скрытом виде. Пользователь заинтересован в том, чтобы не раздавать его налево-направо, поскольку в онлайне может быть только один клиент с именно таким ключом.
Сломал комп --> купил новый --> запустил программу на новом --> всё работает без шаманства (с точки зрения пользователя).

34

Re: AHK: Схема клиент-сервер от мульти использования

А если сломался носитель на котором была программа? А если дом сгорел вместе с компьютером?

Botsy пишет:

Задача ограничить скрипт от мульти использования.

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

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

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

35

Re: AHK: Схема клиент-сервер от мульти использования

Носитель - трудности пользователя. Надо быть аккуратным. Вот диск с игрой сломается - и всё, ничего не сделаешь. Особенно "Ил-2 штурмовик" - он защищён от копирования. Не буду же я писать в контору 1С "У меня диск сломался, пришлите мне бесплатно новый". А с AutoHotkey проще: можно хоть на флешке, хоть на болванке, хоть на хостинге хранить копию своего экземпляра программы.

36

Re: AHK: Схема клиент-сервер от мульти использования

Да я не просив. Разработчик — не я.

37

Re: AHK: Схема клиент-сервер от мульти использования

А как отправить методом "Send" сразу несколько переменных, или ф-ций ?


var := 500
var2 := 400

F1::

try 
{
	link := "../main.php"
	http := ComObjCreate("WinHTTP.WinHTTPRequest.5.1")
	http.Open("POST", link, False)
	http.SetRequestHeader("Content-Type", "application/x-www-form-urlencoded")
	http_test := "obj=" var
	http_test1 := "obj2=" var2
	http.Send(http_test)
	http.WaitForResponse()
	response := http.ResponseText
}
catch e
{
	msgbox, No internet
}

msgbox, %response%

return

Php файл:


<?php
echo "var " . $_POST["obj"] . "ms. Var2 " . $_POST["obj2"] . "ms"; 
?>

"Send" принимает один параметр, а если я писал два сенда, то отправлялся последний.


HRESULT Send(
  [in, optional] VARIANT Body
);
GD

38

Re: AHK: Схема клиент-сервер от мульти использования

Переменные в параметрах POST-запросов объявляются практически с тем же смыслом, как в скриптах, только конкатенируются в строку через знак равенства, а отделяются друг от друга амперсандом.


httpbin  := "https://httpbin.org/"
api_path := "post"
url      := httpbin . api_path

request_args := [   ["var_name1", "var_value1"]
			, ["var_name2", "var_value2"]
			, ["var_name3", "var_value3"]
			, ["var_name4", "var_value4"]]
str_params := ""
For k, v in request_args {
	str_params .= Format("{}={}&", v[1], v[2])
}
str_params := RTrim(str_params, "&")


result := Post(url, str_params)
MsgBox,% result

Post(url, data) {
	oHTTP := ComObjCreate("WinHttp.WinHttpRequest.5.1")
	oHTTP.Open("POST", url, false)
	oHTTP.SetRequestHeader( "Content-Type", "application/x-www-form-urlencoded")
	oHTTP.Send(data)
	return oHTTP.ResponseText
}

Зайдите на httpbin и ознакомьтесь с API. Чтобы не мучаться с устройством обеих частей, можно вначале продумать архитектуру запросов и уже под неё клепать API своего сервера. Рассмотрите так же JSON формат. Оперировать сущностями объектов, особенно в сложных проектах гораздо удобнее. Где-то на просторах серого форума есть отличная обёртка для AHK от teadrinker.

39 (изменено: Botsy, 2020-11-20 15:33:29)

Re: AHK: Схема клиент-сервер от мульти использования

В общем делаю такую схему:

+ открыть спойлер

https://i.ibb.co/vdR9NT8/sheme.jpg

Код:

+ открыть спойлер

ahk:


F2::
tt := userSID()
try 
{
	link := "../test.php"
	http := ComObjCreate("WinHTTP.WinHTTPRequest.5.1")
	http.Open("POST", link, False)
	http.SetRequestHeader("Content-Type", "application/x-www-form-urlencoded")
	http_test1 := "obj2=" tt
	http.Send(http_test1)
	http.WaitForResponse()
	response := http.ResponseText
}
catch e
{
	msgbox, No internet connection.
}
msgbox, %response%
return

php:


<?php
$InputID = $_POST["obj2"];
$link = mysqli_connect("localhost", "bd_test", "12345");
if (!$link) 
{
  die("Connection failed");
}

$sql_check = "SELECT `keys`, `sid` FROM `bd_test`.`pas`";
$result_check = mysqli_query($link, $sql_check);

$array_all = mysqli_fetch_all($result_check, MYSQLI_ASSOC);
$array_check = array_search($InputID, array_column($array_all, 'sid'));

if ($InputID == "")
{
	mysqli_close($link);
	exit;
}
if ($array_check == true)
{
	$OutputP = $array_all[$array_check]["keys"];
	print $array_all[$array_check]["keys"];
}
else
{
	$new_keys = gen_keys(16);
	$hash = password_hash($new_keys, PASSWORD_DEFAULT);
	$sql_add = "INSERT INTO `bd_test`.`pas`(`Keys`, `SID`) VALUES ('$hash', '$InputID')";
	$result_add = mysqli_query($link, $sql_add);
	print $new_keys;
}

function gen_keys($length = 6)
{				
	$chars = 'qazxswedcvfrtgbnhyujmkiolp1234567890QAZXSWEDCVFRTGBNHYUJMKIOLP!@#$%^&*()'; 
	$size = strlen($chars) - 1; 
	$password = ''; 
	while($length--) 
	{
		$password .= $chars[random_int(0, $size)]; 
	}
	return $password;
}
mysqli_close($link);
?>

php файлик лежит просто на сервере. Если его открыть в браузере - будет пустая страница, т.к. переменная "inputID" пустая. Результаты выводятся через print, которые ahk скрипт и получает в "ResponseText". Ключи генерятся и преобразуются в хеш, перед занесением в базу. Однако клиенту выводит ключ до хеша, в норм виде.
Вопрос вот в чем:
- если выполнить ahk скрипт второй раз на одном пк, то в ответ придет ключ в хеш виде (потому что он в бд храниться в хеш), и соответственно ahk должен его преобразовать в нормальный вид и показать пользователю. Как я понимаю, нужно в первый раз (когда приходит ключ в норм виде) сохранять его где-то в реестре или в файле каком-то ? Что бы потом его подтянуть и показать клиенту(если он не сохранил его в первый раз).
- Не будет проблем, что доступ к бд прописан открытым видом ? Т.е. просто в файле, который условно доступен или надо как-то по другому ?

Подскажите если кто знает, спс.

GD

40 (изменено: KusochekDobra, 2020-11-20 17:39:40)

Re: AHK: Схема клиент-сервер от мульти использования

Содержимое PHP-сценариев доступно только по прямому доступу из файловой системы, при запросах они ВСЕГДА попадают в интерпретатор и выполняются. Если Вы нарочно не оставите нигде лазеек, то никто и никогда не узнает, что они содержат.

В PHP, довольно много встроенного функционала. Прежде чем писать свой "велосипед", освойтесь в новом окружении. Хранить идентификаторы в базе в зашифрованном виде — хорошая практика. Однако используют этот подход не так. "Прилетающие" от юзеров идентификаторы, должны применяться лишь к идентификации самих пользователей и вот они то и хранятся в базе в зашифрованном виде. При хешировании идентификаторов, их ещё "подсаливают" для надёжности. Данные же, оперируемые контекстом запроса от лица прошедшего идентификацию юзера используются "как есть". Если желаете и их превращать в криптографическую последовательность, используйте для этого специальный функционал(например: enc, dec).

Например, в Вашем случае:
* "Прилетевший" от пользователя SID, должен быть "подсолен" и превращён в хэш.
* Проверяется его наличие в БД, если он существует, из БД забираются соответствующие данные имеющие как правило, связь по первичному ключу с другой таблицей, в которой они лежат. Можно, конечно и в одной таблице всё хранить, если архитектура данных не сильно замороченная и не предвидится её расширений. Иначе потом, отделять "мух от котлет"...
* Если не существует — соответственно, кладём этот хэш в БД и собираем для него данные(они же "ключ").

Иными словами, самих идентификаторов, в "исходном" виде, у Вас, нет. Это защищает от кражи данных из БД тем, что, если по запросу в Ваше API прилетит такой украденный хэш, то он пройдёт вначале процедуру хеширования, а значит, данные, принадлежащие Вашим пользователям, доступны ему не будут.

Ещё один не мало важный момент в том, чтобы на стороне сервера проводить валидацию данных на предмет отсутствия символов, которых запрос содержать не должен. Это защитит от SQL-инъекций и в целом, сделает работу надёжнее и стабильней.

41

Re: AHK: Схема клиент-сервер от мульти использования

KusochekDobra У меня не большая задача для php, решил сделать велосипед из сухих команд в документации). Ну с SID клиента понял, добавлю для них хеширование, так же как и для ключа лицензии. Но с ключом лицензии тема не раскрыта или я не понял из вашего ответа.

- если выполнить ahk скрипт второй раз на одном пк, то в ответ придет ключ лицензии в хеш виде (потому что он в бд храниться в хеш), и соответственно ahk должен его преобразовать в нормальный вид и показать пользователю. Как я понимаю, нужно в первый раз (когда приходит ключ в норм виде) сохранять его где-то в реестре или в файле каком-то ? Что бы потом его подтянуть и показать клиенту(если он не сохранил его в первый раз).

В первый раз ответ будет такой:
* SIDa в бд не было, php сгенерировал ключ лицензии. В Бд занес его в хеше, а клиенту показал в чистом виде.

ключ лицензии
https://i.ibb.co/3RKvhnt/key.jpg

Во второй раз, ответ будет такой:
* SID в бд был, php взял значение ключа лицензии(в хеш виде) привязанного к этому SID и вернул его клиенту. Потому что при повторном обращении ключ лицензии нигде не хранится в чистом виде.

ключ лицензии уже в хеш
https://i.ibb.co/9wfCnwD/hash.jpg

GD

42

Re: AHK: Схема клиент-сервер от мульти использования

Шифрование нужно для чего? Верно — защиты данных. Поскольку данные всегда кому-то принадлежат, линию обороны Вы выстраиваете вокруг персоны, или идентификаторов, которые её представляют. Если Вы не справляетесь с этим, всё остальное — не важно. А если справляетесь, то от кого Вы шифруете данные? От себя?

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

KusochekDobra пишет:

Данные же, оперируемые контекстом запроса от лица прошедшего идентификацию юзера используются "как есть". Если желаете и их превращать в криптографическую последовательность, используйте для этого специальный функционал(например: enc, dec).

Сформулируйте пожалуйста задачу для себя правильно и если всё ещё не будет понятно, пишите.

И помните, если Вас никто не гонит, то и сами не торопитесь. Понимание не приходит по щелчку выключателя.

43

Re: AHK: Схема клиент-сервер от мульти использования

Я думал так: в бд хранить в защищенном виде(ну чтобы если вытащить данные из бд, то они все равно будут не читаемы, т.к. "hash_password" использует необратимый алгоритм хеширования). А чтобы клиенту было легче отправлять в телегу ключ лицензии, то клиенту показывать его не в защищённом виде(все таки 16 символов более читаемы чем 60+).

GD

44

Re: AHK: Схема клиент-сервер от мульти использования

Botsy пишет:

т.к. "hash_password" использует необратимый алгоритм хеширования

Если это утверждение верно, то как Вы собираетесь восстанавливать данные?

45

Re: AHK: Схема клиент-сервер от мульти использования

Если ключ этот нужен только для инициализации процесса оплаты и не содержит какого-либо осмысленного руководства, то какая разница, что окажется в буфере клиента, если всё, что от него затем требуется, это "Ctrl+V" в эдитбоксе, ожидающем этого ключа?

46

Re: AHK: Схема клиент-сервер от мульти использования

И если это так, то это шифрование ключа вообще не несёт какого-то смысла.
Генерируется ключ -> затем его хэш -> и он же сохраняется. Затем Вы собираетесь сравнивать что с чем, чтобы убедиться в валидности?

47

Re: AHK: Схема клиент-сервер от мульти использования

KusochekDobra А что восстанавливать ?
- SID уникален и пользователю его не изменить. Новый SID - новая копия лицензии.
- "Ключ лицензии" привязан к SID в базе данных и копии скрипта в ahk(лиц. версия. Изначально же у клиента демо версия).
Обе эти сущности спасает постоянный дамп БД. Или я что-то не понимаю ?

GD

48

Re: AHK: Схема клиент-сервер от мульти использования

KusochekDobra пишет:

Генерируется ключ -> затем его хэш -> и он же сохраняется. Затем Вы собираетесь сравнивать что с чем, чтобы убедиться в валидности?

Так вот как раз для этого, я и спрашивал про

если выполнить ahk скрипт второй раз на одном пк, то в ответ придет ключ лицензии в хеш виде (потому что он в бд храниться в хеш), и соответственно ahk должен его преобразовать в нормальный вид и показать пользователю. Как я понимаю, нужно в первый раз (когда приходит ключ в норм виде) сохранять его где-то в реестре или в файле каком-то ? Что бы потом его подтянуть и показать клиенту(если он не сохранил его в первый раз).

Ведь валидность ключа тогда я смогу проверять при помощи "password_verify()"

GD

49

Re: AHK: Схема клиент-сервер от мульти использования

KusochekDobra пишет:

Генерируется ключ -> затем его хэш -> и он же сохраняется.

Тут сказано про то, что это "масло масляное". Создаются уникальные данные, из которых создаются уникальные данные, затем, первая часть пропадает навсегда — улавливаете?

Валидность данных проверяется по месту хранения оригинальных данных, так как доступ к этим данным ограничен и никто не может их изменить. Если Вы собираетесь проверять валидность на клиенте, то это тот путь, с которого, Вы, вроде как свернули(когда клиент сам себе разрешения выписывает). Следовательно, если их проверять на сервере, то — как? Вы собираетесь вновь сгенерировать уникальную последовательность, чтобы из неё сгенерировать другую уникальную последовательность и проверить, совпадает ли она с той, что хранится в БД?

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

50

Re: AHK: Схема клиент-сервер от мульти использования

Если пользователя идентифицирует SID, зачем ещё какой-то ключ нужен?

51

Re: AHK: Схема клиент-сервер от мульти использования

Вы же когда логинетесь на форуме или в сетях, вы вбиваете свой пароль в нормальном виде, а в не в хеше, верно же ? ) Хотя в БД он хранится в хеше(странно будет если не в хеше). Вот и тут точно так же, ключ лицензии в нормальном виде, а в БД он в хеше и при работе скрипта я буду его проверять(на стороне сервера, в файлике php).
Только клиент не будет же запоминать этот ключ, вот я и подумал записывать его в реестр или в файлик какой, а потом подтягивать перед проверкой.

Либо я не понятно пишу, либо я не понимаю концепции. Время покажет.

GD

52 (изменено: KusochekDobra, 2020-11-21 16:04:33)

Re: AHK: Схема клиент-сервер от мульти использования

YMP, подозреваю, что SID нужен для идентификации клиента, а ключ, для идентификации оплаченных услуг, просто схема:

Botsy пишет:

В общем делаю такую схему:

+ открыть спойлер

https://i.ibb.co/vdR9NT8/sheme.jpg

этого не описывает. Нужно догадываться, как, вероятно и о каких-то деталях ещё, в которые, как видно ТС считает, что мы обязательно посвящены, а значит подразумеваем это в своих ответах "by default".

Botsy,

Botsy пишет:

Вы же когда логинетесь на форуме или в сетях, вы вбиваете свой пароль в нормальном виде, а в не в хеше, верно же ? ) Хотя в БД он хранится в хеше(странно будет если не в хеше).

KusochekDobra пишет:

Например, в Вашем случае:
* "Прилетевший" от пользователя SID, должен быть "подсолен" и превращён в хэш.

А так же:

KusochekDobra пишет:

Данные же, оперируемые контекстом запроса от лица прошедшего идентификацию юзера используются "как есть". Если желаете и их превращать в криптографическую последовательность, используйте для этого специальный функционал(например: enc, dec).

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

KusochekDobra пишет:

Сформулируйте пожалуйста задачу для себя правильно и если всё ещё не будет понятно, пишите.

Пока что, Ваше описание выглядит как попытка собрать паззл из пластинок в разном агрегатном состоянии.

53

Re: AHK: Схема клиент-сервер от мульти использования

Я вообще не понимаю, откуда такие сложные алгоритмы. Если пользоваться будут менее 1000 человек, можно в каждый скрипт внедрить уникальный ключ. И все эти ключи администратор введёт вручную на сервере по мере продажи программы. Работающий клиент авторизуется на сервере каждые 5 минут. Если авторизуется двое с одинаковым ключом, одного из них должно выкидывать.

54

Re: AHK: Схема клиент-сервер от мульти использования

KusochekDobra пишет:

подозреваю, что SID нужен для идентификации клиента, а ключ, для идентификации оплаченных услуг

Да, пока не очень понятно. Скрипт привязывается к компьютеру, а не к человеку. Соответственно, зачем нужен ключ? Факт оплаты может обозначаться просто наличием SID'a в базе. Если он там есть, значит запуск скрипта на этом компьютере разрешён. Если нету, запрещён. Оплатил — твой SID заносится в базу.

55

Re: AHK: Схема клиент-сервер от мульти использования

Тут очень спорно, коллеги. До тех пор, пока детали не известны, может даже быть и так, что схема наоборот — недостаточно сложна. Пока не сформулирована задача возможно даже требуется получать результат анализа на COVID-19, или мазок брать и тестом на ДНК закреплять, под роспись ген. прокурора...

56 (изменено: Botsy, 2020-11-21 19:54:08)

Re: AHK: Схема клиент-сервер от мульти использования

YMP
"Если пользователя идентифицирует SID, зачем ещё какой-то ключ нужен?"
Одного SID не достаточно. Ключ лицензии нужен для оплаты, для верификации, для восстановления копии(если что-то с компом будет и т.д.) для сессии(наверно). Да и для будущего расширения, вдруг пригодится.

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

Может я и не прав в общей концепции, но другой пока не придумал.

ypppu
"Если авторизуется двое с одинаковым ключом, одного из них должно выкидывать."
Условно для этого и нужен SID, чтобы определить кого выкинуть(ну на самом деле не выкинуть, а не дать подключиться).

В целом ко всему, буду искать способы разделить скрипт и часть вынести на сервер.
Если вы спросите: "зачем вот это вот всё нужно, что же там за скрипт?". То отвечу, что скрипт тут не важен. Мне это интересно, такая архитектура и как это работает. А потом обязательно пригодится.

UPD. Позже нарисую и выложу полную схему, может в третий раз получится.

GD

57

Re: AHK: Схема клиент-сервер от мульти использования

"Если пользователя идентифицирует SID, зачем ещё какой-то ключ нужен?"
У меня схожий вопрос. Если есть ключ, зачем ещё какой-то SID нужен? Чтобы на одном компьютере запускать программу мог только один пользователь?

58

Re: AHK: Схема клиент-сервер от мульти использования

Чтобы одним ключом мог пользоваться один человек и только на определенном пк.

GD

59

Re: AHK: Схема клиент-сервер от мульти использования

Ну вроде в этот раз ничего не забыл.

https://i.ibb.co/DQ1sVkK/sheme.jpg

GD

60

Re: AHK: Схема клиент-сервер от мульти использования

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

Вот Вы говорите — "Концепция". Взмахиваете этим понятием, словно оно само по себе пропитано мудростью от которой Вы питаетесь, как от розетки. Концепция — это набор некоторых правил, стратегий, определений несущих положительный смысл описания какого-то объекта. Этому определению нужно соответствовать, Ваша же "Концепция" полна противоречий. Вам на них даже по отдельности указывают. Но нет, Вы вплетаете их по новому, когда, казалось бы уже разобрались, или привносите новые. Взять хотя бы Вашу другую тему, в которой Вы собираетесь вынести часть сценария во вне, но даже при беглом просмотре последней схемы видно, что БД, Вы и ныне рассматриваете в том же контексте, в котором рассматривали файл в первом посту. Плюс, клиент сам себе разрешение определяет...

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

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

Ваших знаний недостаточно, даже для того, чтобы Вам было понятно, о чём с Вами говорят, а раз так, то нет уверенности и в том, что Вы сами понимаете, чего хотите.

По крайней мере, мы попробовали.

Вы, главное, не сдавайтесь. Дорогу осилит идущий.

61

Re: AHK: Схема клиент-сервер от мульти использования

Снова я не прав, ну ладно... Спс за ваше потраченное время; за всю воду; и за честность в юбилейном 60-ом посту.

P.s. Судя по вашему объяснению слова "концепция", мы понимаем его совершенно по разному. Для меня это всего лишь алгоритм решения задачи.

GD