Перевод текста на русский язык:

Ранее:

Это довольно запутанное ранее.

Я упоминал об авторизованной версии для расчёта налогов на сайте sxw.ptbird.cn, что я сам разработал схему авторизации для C# winform. Зачем это нужно? Потому что я изначально проигнорировал авторизацию, действительно проигнорировал!

Поскольку я сам не занимаюсь разработкой C# Winform, я также не знаю, как должна быть реализована авторизация, и нет подходящего решения в интернете. Поэтому после того, как я написал программное обеспечение, мне пришлось решать вопрос о необходимости реализации схемы авторизации, а если она нужна, то как её реализовать.

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

Описание:

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

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

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

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

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

Только после успешной авторизации можно использовать основное окно winform программного обеспечения.

Реализация:

Несколько ключевых моментов:

1. Обеспечение определённости локальной проверки. (Локальная проверка требует сохранения доказательства авторизации, без необходимости повторной проверки авторизации)
2. Обеспечение надёжности авторизации.
3. Обеспечение изменчивости содержания авторизации.

Процесс авторизации:

1. Определить, была ли уже авторизована локальная машина. Если нет, выполнить авторизацию.
2. Ввести имя и соответствующий код авторизации и проверочный код для отправки запроса на проверку.
3. Сервер выполняет проверку авторизации.
4. Записать информацию об авторизации локальной машины.
5. Завершить авторизацию.

Часть 1: Стратегия локальной авторизации (код машины)

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

Зачем получать так много кодов?

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

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

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

(Первая строка — это код машины, вторая строка будет обсуждаться позже)

Открытая версия использует ключ, и этот ключ является фиксированным.

Однако в реальной версии, которую я использую, этот ключ получается через запрос сервера и возвращает зашифрованную строку, которая смешивается с кодом машины и снова шифруется.

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

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

Также требуется регистрация авторизации.

Часть 2: Стратегия локальной авторизации (да-код)

Да-код — что это такое?

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

Разработана стратегия да-кода, основанная на другом методе шифрования кода машины. Мы все знаем, что для расшифровки DES требуется ключ (у меня всё ещё есть серьёзное отношение к криптографии), и ключ, возвращаемый машиной, не является тем же ключом. Таким образом, используется ключ DES, и код машины шифруется в соответствии с определёнными правилами (я использую md5 и des, смешанные с различными строками), создавая да-код, также известный как длинная строка во второй строке изображения выше, записывая её.

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

Часть кода выглядит следующим образом: //Проверяем, совпадает ли код лицензии с кодом локальной машины, и требуем регистрации, если они не совпадают. Также требуется регистрация, если файл не существует. public bool checkCode() { //Проверка существования guid и файла try { if (File.Exists(@""+""+this.file)) { StreamReader sr = new StreamReader(this.file, Encoding.Default); string line; if ((line = sr.ReadLine()) != null) { string tmpGuid=this.Decrypt(line); //Требуется расшифровка //Проверка соответствия идентификатора записи текущему компьютеру //Если они не совпадают, требуется регистрация. Если они совпадают, проверяется, является ли да-код включённым if (tmpGuid.Equals(this.guid)) { //Чтение второй строки if ((line = sr.ReadLine()) != null) { tmpGuid = this.Decrypt(line);//Требуется расшифровка if (tmpGuid.Equals(this.checkStatus)) { sr.Close(); return true; } } } } sr.Close(); } return false; }catch(Exception ex){ return false; }

Часть 3: Стратегия авторизации регистрации (реализация архитектуры C/S)

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

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

Процесс регистрации авторизации следующий:

1. Пользователь покупает программное обеспечение.
2. Добавьте сгенерированный код пользователя и проверочный код (я использовал два кода).
3. Пользователь запрашивает регистрацию авторизации онлайн.
4. Сервер выполняет проверку.
5. Авторизация завершена.

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

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

Вот почему мой атрибут cs url — это URL-адрес для запроса проверки.

Определение следующее: private string url = "http://127.0.0.1/sxwTaxCaculation/postbird_license.php/";

Он используется для отправки запросов.

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

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

Код авторизации и проверочный код пользователя на сервере (я добавил количество подключений mac-адресов, максимум пять компьютеров):

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

http://git.oschina.net/uploads/images/2016/1115/120531_d44af7cb_587276.png «здесь введите заголовок изображения»