Авторизация php mysql сессии: Авторизация через сессию на PHP

Авторизация, сессии (php, mysql)? — Хабр Q&A

Всё можно подменить, если вы ЭЦП не используете. Если боитесь подбора чужого session ID — то нужно этот самый ID сделать длинным, 64 байта например. Если основные опасения — что у пользователя уведут куки с его session ID, то проверяйте user-agent, разрешение экрана, версию flash.

Ответ написан

Вот кое что нашел, возможно пригодится:
habrahabr.ru/blogs/php/13726/
php.ru/forum/viewtopic.php?t=15658

Ответ написан

Комментировать

>а благодаря таблице sessions не храним в куках пароль.

рыдалЪ

Ответ написан

Все что угодно можно подменить. Советую не быть крайне параноиком в этом плане.

Товарищи выше дают крайне полезный совет. Браузер + IP. В другом браузере все равно заново логиниться, а чтобы проще это распознавать, то используйте хэш. md5([browser].[IP])

Ответ написан

Комментировать

Почему бы не посмотреть как сделано в vbulletin, invision или просто какой-нибудь хорошей CMS? Задача авторизации это реально такой баянистый велосипед… заодно подсмотрите всякие интересные штуки типа индивидуальной соли паролей, логин с запоминанием или без, серверную авторизацию как опцию и http only печеньки и прочее и прочее.

Ответ написан

Привязка по ип, а также сверять, что в базе, и что в самих куках

Ответ написан

Делать сессию с привязкой по данным, снимаемым с пользователя, самое популярное — ip адрес, браузер, куки.

Ответ написан

Комментировать

Можно привязать ее IP.

Вообще, примеров по этому поводу в гуле вагон и маленькая тележка 🙂

Ответ написан

По ip привязывать как-то не хочется. А вдруг динамичный ip.

Единственное, сверять user agent браузера. Больше ничего в голову не лезит )

Ответ написан

Комментировать

Лучше всего вам разобраться как например сделаны сессии в том же PHP по умолчанию. Касательно вопроса (session_id хранится в куках, его можно подменить) — а вы делайте этоот session_id из 32-64 букв, знаков и цифр. Подменить-то такой ид можно, но сначала надо его подобрать, а это годы работу суперкомпьюетров.

Ответ написан

Имхо, стоит сначала определиться:

1) будут ли подменять сессию 90% пользователей?

2) будут ли подделывать useragent те же самые 90%?

Если нет — не стоит задачу усложнять 😉 ИМХО.

Ответ написан

Комментировать

Проблема авторизации в Битрикс

Главная

Проблема авторизации в Битрикс

14.08.2015


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


Характерные признаки проблемы:

  • Появляется урл вида: bitrix/admin/index.php?_r=3456#authorize где r=3456 меняется на любое число с каждой попыткой

  • Ошибок никаких не выдает

  • Вирусов и внедрений на сайте нет.


Основные признаки: похоже на проблему сохранения сессии


Решение проблемы:


В этом конкретном случае сессии хранятся в БД (таблица b_sec_session). Она была повреждена и авторизация не срабатывала. После исправления таблицы авторизация работает.


Нужно восстановить только одну таблицу в базе данных b_sec_session, поможет команда: mysqlcheck -r db_name table_name -uroot -p 


После восстановления таблицы получил такую ошибку (до этого ошибки не выдавались): 


	 Bitrix\Main\DB\SqlQueryException] 
	 Mysql query error: (145) Table './.../b_sec_session' is marked as crashed and should be repaired (400)
	 SELECT 
	 `security_session`.`SESSION_DATA` AS `SESSION_DATA`
	 FROM `b_sec_session` `security_session` 
	 WHERE `security_session`.`SESSION_ID` = 'l5fvkBD94rIlLuP05j16I0VvEM7ZfncC'
	 LIMIT 0, 1

После этого полностью очистил таблицу b_sec_session и смог авторизоваться

После очистки таблицы также можно будет авторизоваться и исправить повреждения таблицы с помощью встроенных инструментов проверки системы


С чем это связано и как избежать в будущем?    


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


Чтобы увеличить надежность таблиц рекомендуется перевести их в формат InnoDB вместо MyISAM (если эта возможность поддерживается на хостинге). Модуль «монитор производительности» позволяет выполнить эту операцию из административного интерфейса.


Вот ещё чек-лист возможных проблем если пропадает авторизация


https://dev.1c-bitrix.ru/learning/course/index.php?COURSE_ID=35&LESSON_ID=2167&LESSON_PATH=3906.4503.2167

Ещё статьи:

18.01.2023
Нюансы перехода битрикс на РНР 8.0
С февраля битрикс прекращает поддерживать РНР 7.4 и в битрикс сегменте сайтов начался переход на РНР 8 для получения обновлений.
Но без нюансов и ошибок…
ID: 431

10.01.2023
БУС окончательно всё?
Появилась информация от битрикс, что грубо говоря поддержка по отраслевому медицинскому решению от битрикс будет до 1 февраля 2024 года, а что потом б. ..
ID: 426

30.08.2022
Типовые претензии к подрядчику и к битрикс
По свежим следам я собрал типовые претензии к подрядчику и к битрикс. Мной был проведён аудит и я увидел, что техническое состояние сайта хорошее, нареканий…
ID: 338

Новые статьи в блоге:

27.04.2023
Любой фастобмен мошенники на любом домене FASTOBMEN
Любой фастобмен на любом домене FASTOBMEN — это мошенники, я бы назвал это франшизой обмана. Никаких обменов денег и валют они не делают, а блокируют …
ID: 454

25.04.2023
Тест виртуальный сервер RED.Site-1
Параметры хостинга:
VPS reddock.ru
Дисковое пространство -20Гб
Оперативная память — 2Гб
Ядро — нет данных.
Цена в месяц — 1000 руб
Есть панель
ID: 453

25.04.2023
Битрикс ошибка Cache engine is not found
Если в настройках битрикс стоит тип кеша memcache, а при переходе на РНР 8 у вас ошибка Cache engine is not found
ID: 452

Возврат к списку

Управление сеансом

— как лучше всего создать «токен» для аутентификации пользователя

Краткая версия:

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

Если вы хотите пойти по маршруту «случайных данных», иногда рекомендуется хранить хэш токена на стороне сервера и хешировать отправленный пользователем токен перед проверкой (это простой способ избежать атак по времени на чек).

Похоже, вы пытаетесь заново изобрести модель «токен доступа + токен обновления». Оставляя в стороне, возможно, не относящиеся к делу вещи (почему у вас есть сервер Node, расположенный между вашими пользователями и серверной частью PHP?), похоже, что вы пытаетесь разработать какой-то токен долгосрочного доступа.

Теоретически это тривиально; просто сгенерируйте безопасно случайную строку байтов — 16 байтов из /dev/urandom в порядке — а затем закодируйте ее в шестнадцатеричном или base64-кодировании и используйте ее в качестве токена доступа (предоставляется клиенту, и клиент передает его с помощью каждый запрос). Сервер поддерживает словарь в памяти сеансов пользователей и, получив токен, просматривает его в словаре сеансов, чтобы получить информацию о пользователе. Сеансы имеют срок действия (возможно, известный клиенту, но , установленный сервером , после чего пользователю необходимо снова войти в систему, но до истечения срока действия могут пройти годы или десятилетия, если вы действительно этого хотите. Сервер также должен поддерживать аннулирование токена (выход из системы) по запросу до истечения срока его действия.

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

Обычное решение состоит в том, чтобы передать максимально возможное состояние клиенту, а не серверу, но подписать его с помощью ключа, известного только серверу, чтобы злоумышленник не мог изменить состояние своего сеанса (например, выдавать себя за другого пользователя). Обычно это делается с помощью веб-токена JSON, сокращенно JWT; это стандартизированный формат токенов, состоящий из трех частей, который включает в себя метаданные (эмитент, срок действия и т. д.), данные сеанса (идентификация пользователя, разрешения и все, что вам нужно) и подпись поверх двух других частей (для предотвращения модификации). Отличительной особенностью JWT является то, что они вообще не требуют состояния сеанса на стороне сервера или поиска в БД — если токен находится в пределах срока действия и подпись проверена, вы можете доверять всем данным в JWT — поэтому они отлично подходят для масштабирование. Проблема с JWT заключается в том, что нет хорошего способа отозвать их или динамически понизить их привилегии; поскольку сервер не хранит состояние сеанса, он не может сказать, когда вы хотите изменить сеанс или завершить его преждевременно.

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

Общий процесс выглядит следующим образом:

  1. Пользователь заходит на страницу входа, предоставляет учетные данные.
  2. Сервер проверяет учетные данные, генерирует токен обновления и токен доступа (вероятно, JWT) обратно клиенту.
  3. Клиент включает JWT с каждым запросом в течение нескольких минут, позволяя серверу отслеживать состояние сеанса без необходимости сохранять это состояние между запросами.
  4. Клиент периодически использует токен обновления для запроса нового JWT, который будет действителен еще несколько минут.
  5. Если клиент уходит без выхода из системы, срок действия JWT истечет, но токен обновления останется действительным, поэтому пользователь может возобновить сеанс без необходимости повторного входа в систему, просто используя токен обновления (как в # 4).
  6. Если клиент выходит из системы (или сеанс прерывается по какой-либо иной причине), токен обновления удаляется из БД. Теоретически пользователь может продолжать использовать токен доступа (JWT) в течение короткого времени, но больше не может обновлять его и должен будет снова войти в систему.

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

По крайней мере, если вы используете JWT, используйте для них библиотеку. Генерация и проверка случайных токенов не слишком сложна для безопасного выполнения (хотя в идеале вы хотите избежать таких вещей, как атаки по времени при сравнении строк), но более сложные типы токенов с цифровыми подписями и т. д. должны обрабатываться кодом библиотеки. Честно говоря, если вам нужно спросить «совершенно случайно» вместо «комбинация букв + цифр», вы должны позволить другим людям справиться с этим.

Учебник. Приложение PHP с MySQL — служба приложений Azure

  • Статья

Служба приложений Azure предоставляет высокомасштабируемую службу веб-хостинга с автоматическим исправлением, использующую операционную систему Linux. В этом руководстве показано, как создать безопасное приложение PHP в службе приложений Azure, подключенное к базе данных MySQL (с помощью базы данных Azure для гибкого сервера MySQL). Когда вы закончите, у вас будет приложение Laravel, работающее в службе приложений Azure в Linux.

Из этого руководства вы узнаете, как:

  • Создать безопасное по умолчанию приложение PHP и MySQL в Azure
  • Настройте секреты подключения к MySQL с помощью параметров приложения
  • Разверните код приложения с помощью GitHub Actions
  • Обновите и повторно разверните приложение
  • Безопасное выполнение миграции базы данных
  • Поток журналов диагностики из Azure
  • Управление приложением на портале Azure

Если у вас нет подписки Azure, перед началом работы создайте бесплатную учетную запись Azure.

Образец приложения

Чтобы следовать этому руководству, клонируйте или загрузите образец приложения из репозитория:

 git clone https://github.com/Azure-Samples/laravel-tasks.git

Если вы хотите запустить приложение локально, выполните следующие действия:

  • В .env настройте параметры базы данных (например, DB_DATABASE , DB_USERNAME и 9001 4 DB_PASSWORD ), используя настройки в вашем локальном MySQL база данных. Для запуска этого примера вам нужен локальный сервер MySQL.

  • Из корня репозитория запустите Laravel с помощью следующих команд:

     установка композитора
php ремесленник миграция
ключ ремесленника php: сгенерировать
php ремесленник служить

1 — Создание службы приложений и ресурсов MySQL

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

  • Имя для веб-приложения. Это имя, используемое как часть имени DNS для вашего веб-приложения в форме https://.azurewebsites.net .
  • Среда выполнения для приложения. Здесь вы выбираете версию PHP для своего приложения.
  • Группа ресурсов для приложения. Группа ресурсов позволяет сгруппировать (в логическом контейнере) все ресурсы Azure, необходимые для приложения.

Войдите на портал Azure и выполните следующие действия, чтобы создать ресурсы службы приложений Azure.

Инструкции Скриншот
На портале Azure:

  1. Введите «база данных веб-приложения» в строке поиска в верхней части портала Azure.
  2. Выберите элемент с меткой Web App + Database под заголовком Marketplace .

Вы также можете напрямую перейти к мастеру создания.

На странице Создать веб-приложение + базу данных заполните форму следующим образом.

  1. Группа ресурсов → Выберите Создайте новый и используйте имя msdocs-laravel-mysql-tutorial .

  2. Регион → Любой регион Azure рядом с вами.

  3. Имя → msdocs-laravel-mysql-XYZ , где XYZ — любые три случайных символа. Это имя должно быть уникальным в Azure.

  4. Стек времени выполнения → PHP 8.0 .

    MySQL — Гибкий сервер выбран для вас по умолчанию в качестве ядра базы данных. База данных Azure для MySQL — это полностью управляемая база данных MySQL как служба в Azure, совместимая с последними выпусками сообщества.

  5. Обратите внимание на сгенерированное для вас имя базы данных ( -database ). Он понадобится вам позже.

  6. Нажмите Проверить + создать .

После завершения проверки нажмите Создать 9009.6 .

Развертывание занимает несколько минут и создает следующие ресурсы:

  • Группа ресурсов → Контейнер для всех созданных ресурсов.
  • План службы приложений → Определяет вычислительные ресурсы для службы приложений. План Linux на уровне P1v2 создан.
  • Служба приложений → Представляет ваше приложение и выполняется в плане службы приложений.
  • Виртуальная сеть → Интегрировано с приложением службы приложений и изолирует внутренний сетевой трафик.
  • Гибкий сервер базы данных Azure для MySQL → Доступен только из виртуальной сети. Для вас на сервере создается база данных и пользователь.
  • Частная зона DNS → Включает разрешение DNS сервера базы данных MySQL в виртуальной сети.

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

2 — Настройка подключения к базе данных

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

Инструкции Скриншот
На странице службы приложений в меню слева выберите Конфигурация .
На вкладке Application settings страницы Configuration создайте параметр DB_DATABASE :

  1. Нажмите Новая настройка приложения .

  2. В поле Имя введите DB_DATABASE .

  3. В поле Value введите автоматически сгенерированное имя базы данных из мастера создания, которое выглядит как msdocs-laravel-mysql-XYZ-database .

  4. Нажмите OK .

Вернуться на вкладку настроек приложения:

  1. Прокрутите вниз и выберите строку подключения defaultConnection . Он был сгенерирован мастером создания и содержит нужные вам имя пользователя и пароль.

  2. В поле Значение выберите кнопку Копировать и вставьте значение в текстовый файл для последующего использования. Это в следующем формате (разрывы строк для ясности):

     База данных=mysql;
Server=<имя-домена-сервера-базы-данных>;
Идентификатор пользователя=<имя пользователя>;
Пароль=<пароль>

  3. Выбрать Отмена .

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

  • DB_HOST : используйте из скопированной строки подключения в качестве значения.

  • DB_USERNAME : используйте из скопированной строки подключения в качестве значения.

  • DB_PASSWORD : Используйте <пароль> из скопированной строки подключения в качестве значения.

  • MYSQL_ATTR_SSL_CA : используйте /home/site/wwwroot/ssl/DigiCertGlobalRootCA.crt.pem в качестве значения.

    Этот параметр приложения указывает путь к сертификату TLS/SSL, необходимому для доступа к серверу MySQL. Он включен в репозиторий примеров для удобства.

  • APP_DEBUG : Используйте true в качестве значения. Это переменная отладки Laravel.

  • APP_KEY : используйте base64:Dsz40HWwbCqnq0oxMsjq7fItmKIeBfCBGORfspaI1Kw= в качестве значения. Это переменная шифрования Laravel.

    Важно

    Это значение APP_KEY используется здесь для удобства. Для производственных сценариев он должен быть сгенерирован специально для вашего развертывания с использованием php artisan key:generate --show в командной строке.

3 — Пример кода развертывания

На этом этапе вы настроите развертывание GitHub с помощью действий GitHub. Это всего лишь один из многих способов развертывания в службе приложений, а также отличный способ обеспечить непрерывную интеграцию в процесс развертывания. По умолчанию каждый git push в ваш репозиторий GitHub запускает действие сборки и развертывания. Вы внесете некоторые изменения в кодовую базу с помощью Visual Studio Code прямо в браузере, а затем разрешите автоматическую установку GitHub Actions.

Инструкции Скриншот
В новом окне браузера:

  1. Войдите в свою учетную запись GitHub.

  2. Перейдите к https://github.com/Azure-Samples/laravel-tasks.

  3. Щелчок Вилка .

  4. Нажмите Создать ответвление .

На странице GitHub откройте Visual Studio Code в браузере, нажав . ключ .
В коде Visual Studio в браузере откройте config/database.php в проводнике. В соединении mysql убедитесь, что настройки приложения, которые вы создали ранее для соединения MySQL, уже используются ( DB_HOST , DB_DATABASE , DB_USERNAME , DB_PASSWORD , MYSQL_ATTR_SSL_CA ).
Вернувшись на страницу службы приложений, в левом меню выберите Центр развертывания .
На странице центра развертывания:

  1. В Source выберите GitHub . По умолчанию в качестве поставщика сборки выбран GitHub Actions .

  2. Войдите в свою учетную запись GitHub и следуйте инструкциям для авторизации Azure.

  3. В Организация выберите свою учетную запись.

  4. В репозитории выберите laravel-задач .

  5. В Branch выберите main .

  6. В верхнем меню нажмите Сохранить .

Служба приложений фиксирует файл рабочего процесса в выбранном репозитории GitHub в каталоге .github/workflows .

На странице центра развертывания:

  1. Выберите Журналы . Выполнение развертывания уже запущено.

  2. В элементе журнала запуска развертывания выберите Журналы сборки/развертывания .

    Вы попали в свой репозиторий GitHub и видите, что действие GitHub запущено. Файл рабочего процесса определяет два отдельных этапа: сборку и развертывание.

Дождитесь завершения цикла. Это занимает около 15 минут.

Совет

Действие GitHub определяется файлом в вашем репозитории GitHub, в .github/workflow . Вы можете сделать это быстрее, настроив файл.

4 — Создать схему базы данных

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

Инструкции Скриншот
На странице службы приложений:

  1. В меню слева выберите SSH .

  2. Выберите Перейти .

Сеанс SSH с контейнером службы приложений открывается в браузере. При желании вы можете перейти непосредственно к https://.scm.azurewebsites.net/webssh/host .

В терминале SSH:

  1. CD в корень вашего приложения код:

     cd /home/site/wwwroot

  2. Запустите миграцию базы данных из корня приложения.

     php artisan migrate --force

    Примечание

    Только изменения в файлах в /home могут сохраняться после перезапуска приложения. Изменения за пределами /home не сохраняются.

5 — Изменить корень сайта

Жизненный цикл приложения Laravel начинается в 9Вместо этого используйте каталог 0095 /public . Контейнер PHP 8.0 по умолчанию для службы приложений использует Nginx, который запускается в корневом каталоге приложения. Чтобы изменить корень сайта, вам нужно изменить файл конфигурации Nginx в контейнере PHP 8.0 ( /etc/nginx/sites-available/default ). Для вашего удобства репозиторий примеров содержит настраиваемый файл конфигурации с именем default . Как отмечалось ранее, вы не хотите заменять этот файл с помощью оболочки SSH, потому что ваши изменения будут потеряны после перезапуска приложения.

Инструкции Скриншот
На странице службы приложений:

  1. В меню слева выберите Конфигурация .

  2. Выберите вкладку Общие настройки .

Во вкладке Общие настройки:

  1. В поле Startup Command введите следующую команду: cp /home/site/wwwroot/default /etc/nginx/sites-available/default && service nginx reload .

    Заменяет файл конфигурации Nginx в контейнере PHP 8.0 и перезапускает Nginx. Эта конфигурация гарантирует, что это изменение вносится в контейнер при каждом его запуске.

  2. Выбрать Сохранить .

6 — Перейти к приложению

Инструкции Скриншот
На странице службы приложений:

  1. В меню слева выберите Обзор .

  2. Выберите URL вашего приложения.

    Вы также можете перейти непосредственно к https://. azurewebsites.net .

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

7 — поток журналов диагностики

Инструкции Скриншот
На странице службы приложений:

  1. В меню слева выберите Журналы службы приложений .

  2. В разделе Ведение журнала приложений выберите Файловая система .

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

Очистка ресурсов

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

Инструкции Скриншот
В строке поиска в верхней части портала Azure:

  1. Введите имя группы ресурсов.

  2. Выберите группу ресурсов.

На странице группы ресурсов щелкните Удалить группу ресурсов .

  1. Введите имя группы ресурсов, чтобы подтвердить удаление.

  2. Нажмите Удалить .

Часто задаваемые вопросы

  • Сколько стоит установка?
  • Как с помощью других инструментов подключиться к базе данных MySQL, защищенной виртуальной сетью?
  • Как локальная разработка приложений работает с GitHub Actions?
  • Почему развертывание GitHub Actions происходит так медленно?
Сколько стоит установка?

Цены на создание ресурсов указаны ниже:

  • План службы приложений создается на уровне Premium V2 и может масштабироваться вверх или вниз. См. цены на службу приложений.
  • Гибкий сервер MySQL создается на уровне B1ms и может масштабироваться вверх или вниз. С бесплатной учетной записью Azure 9Уровень 0095 B1ms предоставляется бесплатно в течение 12 месяцев до месячного лимита. См. цены на Базу данных Azure для MySQL.
  • Плата за виртуальную сеть не взимается, если вы не настроите дополнительные функции, такие как пиринг. См. цены на виртуальную сеть Azure.
  • За частную зону DNS взимается небольшая плата. См. цены на Azure DNS.
Как подключиться к базе данных MySQL, защищенной виртуальной сетью, с помощью других инструментов?
  • Для базового доступа из инструмента командной строки вы можете запустить mysql из SSH-терминала приложения.
  • Для подключения из настольного инструмента, такого как MySQL Workbench, ваш компьютер должен находиться в виртуальной сети. Например, это может быть виртуальная машина Azure, подключенная к одной из подсетей, или машина в локальной сети, имеющая VPN-подключение типа «сеть — сеть» к виртуальной сети Azure.
  • Вы также можете интегрировать Azure Cloud Shell с виртуальной сетью.
Как локальная разработка приложений работает с GitHub Actions?

В качестве примера возьмем автоматически созданный файл рабочего процесса из службы приложений. Каждый git push запускает новую сборку и развертывание. Из локального клона репозитория GitHub вы отправляете нужные обновления на GitHub. Например:

 git add .
git commit -m "<некоторое-сообщение>"
git push происхождение основной
Почему развертывание GitHub Actions происходит так медленно?

Автоматически созданный файл рабочего процесса из службы приложений определяет запуск двух заданий по схеме «сборка и развертывание». Поскольку каждое задание выполняется в собственной чистой среде, файл рабочего процесса гарантирует, что 9Задание 0014 deploy имеет доступ к файлам из задания build :

  • В конце задания build загрузите файлы как артефакты.