Слияние кода завершено, страница обновится автоматически
Прежде чем приступить к написанию кода, пожалуйста, откройте новую проблему, чтобы описать свою идею, или найдите и продолжите обсуждение в существующей проблеме.
⚠️ Пожалуйста, не публикуйте информацию об уязвимости системы безопасности на GitHub или на форуме сообщества Parse. Вместо этого следуйте Политике безопасности сообщества Parse.
Пожалуйста, полностью заполните все шаблоны, чтобы предоставить необходимую информацию о вашей новой функции или обнаруженной вами ошибке.
Вместе мы спланируем наилучший концептуальный подход для вашего вклада, чтобы ваше и наше время было вложено в наилучший возможный подход. Обсуждение часто показывает, как использовать существующие функции Parse Server для достижения вашей цели с меньшими усилиями и более устойчивым способом.
Когда вы будете готовы к написанию кода, вы можете найти дополнительную информацию об открытии запроса на вытягивание в документах GitHub.
Независимо от того, является ли это вашим первым вкладом или вы уже опытный участник, сообщество Parse поддержит вас — не стесняйтесь обращаться за помощью!
Запрос на вытягивание должен быть связан с каждой проблемой. Мы понимаем, что никому не нравится создавать проблему для чего-то, что кажется простым запросом на вытягивание, но вот почему это полезно для всех:
Можно ли получить доступ для записи в репозиторий, чтобы вносить изменения быстрее?
Обеспечение безопасности наших продуктов — один из ваших главных приоритетов. Наша политика безопасности требует, чтобы доступ на запись к репозиториям предоставлялся только необходимому количеству людей. Все обычные вклады можно сделать через публичные пул-реквесты. Если вы считаете, что вам нужен доступ на запись, свяжитесь с командой репозитория и подробно объясните, какое ограничение вы пытаетесь преодолеть. Мы хотим сделать ваш вклад как можно более лёгким. Если есть какие-либо узкие места, которые замедляют вас, мы будем рады получить ваши отзывы, чтобы увидеть, где мы можем улучшить ситуацию.
Новый частный репозиторий
Могу ли я получить новый частный репозиторий в рамках организации Parse Platform для работы над некоторыми вещами?
Частные репозитории не предоставляются, если нет существенного ограничения или требования, которое делает это необходимым. Например, при совместной работе над устранением уязвимости в системе безопасности мы предоставляем частные репозитории, чтобы участники могли обмениваться конфиденциальной информацией внутри выбранной группы.
Новый публичный репозиторий
Могу ли я получить новый публичный репозиторий в рамках организации Parse Platform для работы над некоторыми вещами?
Прежде всего, мы ценим ваш вклад. В редких случаях, когда мы считаем это полезным для развития репозитория, может быть предоставлен новый публичный репозиторий для конкретной цели, например, для повышения видимости или предоставления ресурсов GitHub организации. В других случаях мы рекомендуем вам начать свой вклад в личном репозитории вашего собственного аккаунта GitHub, а затем перенести его в организацию Parse Platform. Мы будем рады помочь вам в переносе репозитория.
$ git clone https://github.com/parse-community/parse-server
$ cd parse-server # перейдите в каталог клонирования
$ npm install # установите все зависимости узла
$ code . # запустите vscode
$ npm run watch # запустите babel, наблюдая за изменениями локальных файлов
Чтобы запустить VS Code из терминала с помощью команды code, сначала необходимо следовать разделу «Запуск из командной строки» в документации по настройке VS Code.
После того как вы запустите babel в режиме наблюдения, вы можете начать вносить изменения в parse-сервер.
it_exclude_mongodb_version('<4.4') // будет тестироваться с любой версией Postgres и MongoDB, исключая версию MongoDB <4.4; принимает нотацию semver для указания диапазона версий.it_only_postgres_version('>=13') // будет тестироваться с любой версией Mongo, но только с версией Postgres >=13; принимает нотацию semver для указания диапазона версий.it_exclude_postgres_version('<13') // будет тестироваться с любой версией Postgres и MongoDB, исключая версию Postgres <13; принимает нотацию semver для указания диапазона версий.Изображения PostGIS (выберите одно с v2.2 или выше) на docker hub основаны на официальном образе postgres и будут работать «из коробки» (при условии, что вы создадите пользователя с необходимыми расширениями для каждой из ваших баз данных Parse; см. ниже). Чтобы запустить совместимый экземпляр Postgres, скопируйте и вставьте следующую строку в свою оболочку:
docker run -d --name parse-postgres -p 5432:5432 -e POSTGRES_PASSWORD=password --rm postgis/postgis:16-3.4-alpine && sleep 20 && docker exec -it parse-postgres psql -U postgres -c 'CREATE DATABASE parse_server_postgres_adapter_test_database;' && docker exec -it parse-postgres psql -U postgres -c 'CREATE EXTENSION pgcrypto; CREATE EXTENSION postgis;' -d parse_server_postgres_adapter_test_database && docker exec -it parse-postgres psql -U postgres -c 'CREATE EXTENSION postgis_topology;' -d parse_server_postgres_adapter_test_database
Чтобы остановить экземпляр Postgres:
docker stop parse-postgres
Вы также можете использовать образ postgis/postgis:16-3.4-alpine в Dockerfile и скопировать этот скрипт в образ, добавив следующие строки:
#Install additional scripts. These are run in abc order during initial start
COPY ./scripts/setup-dbs.sh /docker-entrypoint-initdb.d/setup-dbs.sh
RUN chmod +x /docker-entrypoint-initdb.d/setup-dbs.sh
Обратите внимание, что приведённый выше скрипт будет выполняться только во время инициализации контейнера без данных в базе данных, подробности смотрите в официальном образе Postgres. Если вы хотите использовать скрипт для повторного запуска, убедитесь, что в /var/lib/postgresql/data контейнера нет данных.
Критических изменений следует избегать, когда это возможно. Для принятия критического изменения преимущества изменения должны явно перевешивать затраты разработчиков на адаптацию своих развёртываний. Если критическое изменение носит лишь косметический характер, оно, скорее всего, будет отклонено и станет устаревшим естественным образом в ходе дальнейшего развития, если только оно не требуется как часть более крупного изменения. Критические изменения должны соответствовать Политике устаревания.
Пожалуйста, учтите, что Parse Server — это всего лишь один компонент в стеке, который требует внимания. Критическое изменение требует ресурсов и усилий для адаптации среды. Чрезмерно высокая частота критических изменений может иметь пагубные побочные эффекты, такие как:
Если вы изменяете или удаляете существующую функцию, которая приведёт к критическому изменению, используйте следующий шаблон устаревания:
Deprecator/Deprecations.js, которое будет... Вывод предупреждающего сообщения об устаревании при запуске Parse-сервера, например:
DeprecationWarning: Опция Parse Server «example» будет удалена в будущем выпуске.
Для устаревших функций, которые могут быть определены только во время выполнения, например, синтаксические устаревания Parse Query, используйте метод Deprecator.logRuntimeDeprecation().
Устаревшие функции становятся критическими изменениями после уведомления разработчиков через предупреждения об устаревании в течение как минимум одного предыдущего основного выпуска. Например:
4.5.0 — текущая версия;4.6.0 добавляет новую необязательную функцию и предупреждение об устаревании существующей функции;5.0.0 начинает регистрировать предупреждение об устаревании для одного основного выпуска;6.0.0 вносит критические изменения, удаляя предупреждение об устаревании и заменяя существующую функцию новой.См. План устаревания для обзора устареваний и запланированных критических изменений.
Функция проверки безопасности Parse Server предупреждает разработчиков о слабых настройках безопасности в их развёртывании Parse Server.
Проверка безопасности должна быть добавлена для каждой новой функции или улучшения, которая позволяет разработчику настроить её таким образом, чтобы ослабить механизмы безопасности или предоставить функциональность, создающую слабое место для злонамеренных атак. Если вы не уверены, требует ли ваша функция или улучшение проверки безопасности, не стесняйтесь спросить.
Например, разрешение публичного чтения и записи для класса может быть полезным для упрощения разработки, но должно быть запрещено в рабочей среде.
Проверки безопасности добавляются в CheckGroups.
Добавление новой проверки безопасности для вашей функции легко и быстро:
Посмотрите в CheckGroups, есть ли существующий файл CheckGroup[Category].js для категории проверки, которую нужно добавить. Например, проверка, касающаяся соединения с базой данных, добавляется в CheckGroupDatabase.js.
Если вы не нашли файл, продублируйте существующий файл и замените название категории в setName() и проверки в setChecks():
class CheckGroupNewCategory extends CheckGroup {
setName() {
return 'House';
}
setChecks() {
return [
new Check({
title: 'Door locked',
warning: 'Anyone can enter your house.',
solution: 'Lock the door.',
check: () => {
return; // Пример успешного прохождения проверки
}
}),
new Check({
title: 'Camera online',
warning: 'Security camera is offline.',
solution: 'Check the camera.',
check: async () => {
throw 1; // Пример неудачной проверки
}
}),
];
}
}
Если вы добавили новый файл на предыдущем шаге, укажите ссылку на файл в CheckGroups.js, который является сборщиком всех проверок безопасности:
export { default as CheckGroupNewCategory } from './CheckGroupNewCategory';
Добавьте тест, который охватывает новую проверку, в SecurityCheckGroups.js для случаев успеха и неудачи.
При добавлении новой проверки безопасности учитывайте следующее:
Введение новых ошибок Parse требует выполнения следующих шагов:
Изучите, не покрывает ли уже существующая ошибка Parse рассматриваемый сценарий ошибки. Помните, что повторное использование уже существующей ошибки Parse не позволяет различать сценарии, в которых возникает одна и та же ошибка, поэтому может потребоваться добавить новую и более конкретную ошибку Parse, даже если уже существует более общая ошибка Parse. ⚠️ В настоящее время (по состоянию на декабрь 2020 года) существуют несоответствия между ошибками Parse, задокументированными в руководствах Parse, закодированными в JavaScript SDK Parse и закодированными на сервере Parse, поэтому исследование доступности кодов ошибок должно проводиться во всех этих источниках.
Добавьте новую ошибку Parse в /src/ParseError.js в JavaScript SDK Parse. Это основной справочник по ошибкам Parse для JavaScript SDK Parse и сервера Parse.
Создайте запрос на извлечение для JavaScript SDK Parse, включая новые ошибки Parse. PR должен быть объединён, и должна быть выпущена новая версия JavaScript SDK Parse.
Измените зависимость JavaScript SDK Parse в package.json сервера Parse на недавно выпущенную версию JavaScript SDK Parse, чтобы новая ошибка Parse распознавалась сервером Parse.
При возникновении новой ошибки Parse в коде не следует жёстко кодировать код ошибки, вместо этого следует ссылаться на код ошибки из ошибки Parse. Например:
throw new Parse.Error(Parse.Error.EXAMPLE_ERROR_CODE, 'Пример сообщения об ошибке.');
throw new Parse.Error(Parse.Error.FILE_SAVE_ERROR, 'Файл не удалось сохранить, поскольку он превысил максимально допустимый размер файла.');
throw new Parse.Error(Parse.Error.FILE_SAVE_ERROR, 'Не удалось сохранить файл, так как формат файла был неправильным.');
Конфигурация сервера Parse
Для введения новых параметров конфигурации сервера Parse необходимо выполнить следующие шаги:
Добавить определения параметров в [/src/Options/index.js][config-index].
Если новый параметр не имеет одного значения, а является группой параметров (объектом, содержащим несколько подпараметров):
nestedOptionEnvPrefix в /resources/buildConfigDefinition.js;nestedOptionTypes в /resources/buildConfigDefinition.js.Например, взгляните на существующий параметр security сервера Parse. Это группа параметров, потому что у неё есть несколько подпараметров, таких как checkGroups. Его интерфейс определён в [index.js][config-index] как export interface SecurityOptions. Поэтому значение, добавляемое к nestedOptionTypes, будет SecurityOptions, значение, добавляемое к nestedOptionEnvPrefix, будет PARSE_SERVER_SECURITY_.
Выполните npm run definitions, чтобы автоматически создать определения в [/src/Options/Definitions.js][config-def] и [/src/Options/docs.js][config-docs].
Добавьте проверку значений параметров в... 5. Добавьте тестовые случаи, чтобы обеспечить правильную проверку значений параметров.
Сервер Parse выдаёт ошибку при запуске, если для любого параметра конфигурации установлено недопустимое значение.
6. Выполните команду npm run docs, чтобы сгенерировать документацию в каталоге /out.
Проверьте документацию на предмет удовлетворительности описания и форматирования вновь введённых параметров.
Для автоматизации выпуска заголовок запросов на вытягивание должен быть написан в определённом синтаксисе. Мы следуем спецификации Conventional Commits, которая определяет этот синтаксис:
<тип>: <резюме>
Тип — это категория вносимого изменения, возможные типы:
Резюме — краткое описание изменений в настоящем времени, не заглавными буквами, без точки в конце. Это резюме также будет использоваться как запись в журнале изменений.
Например:
feat: добавить ручку двери для лёгкого открывания
В настоящее время мы не используем область фиксации, которая записывается как <тип>(<область>): <резюме> и приписывает изменение определённой части продукта.
Если запрос на вытягивание содержит критическое изменение, описание запроса на вытягивание должно содержать специальный раздел внизу, чтобы указать на это. Это поможет автору запроса на вытягивание избежать объединения критического изменения как некритического.
Следующее руководство предназначено для всех, кто объединяет запрос на вытягивание от участника в рабочую ветку, рабочую ветку в ветку выпуска, ветку выпуска в другую ветку выпуска или любые другие прямые коммиты, такие как исправления в ветки выпуска или рабочую ветку.
Если запрос на вытягивание содержит критическое изменение, сообщение о фиксации должно содержать фразу BREAKING CHANGE, написанную заглавными буквами и без какого-либо форматирования, за которой следует краткое описание критического изменения и, желательно, того, как разработчик должен его устранить, всё в одной строке. Эта строка должна содержать больше деталей, фокусируясь на «критическом» аспекте изменения, и предназначена для помощи разработчику в адаптации. ### Отмена изменений
Если коммит отменяет изменения предыдущего коммита, используйте префикс revert:, за которым следует заголовок отменённого коммита. В теле сообщения коммита добавьте This reverts commit <хэш>., где хэш — это SHA отменяемого коммита. Например:
revert: fix: remove handle from door
This reverts commit 1234567890abcdef.
⚠️ Префикс revert всегда инициирует выпуск. Как правило, коммит, который не инициировал выпуск при первоначальном слиянии, также не должен инициировать выпуск при отмене. Например, не используйте префикс revert, когда отменяете коммит с префиксом ci:
ci: add something
отменяется с помощью:
ci: remove something
вместо:
revert: ci: add something
This reverts commit 1234567890abcdef.
Исправления уязвимостей системы безопасности разрабатываются в закрытых ветках с ограниченной аудиторией, недоступных для общественности. Текущее ограничение GitHub не позволяет запускать тесты CI в запросах на вытягивание в частных ветках. Можно определить, полностью ли проходит все тесты CI запрос на вытягивание, только опубликовав исправление как публичный запрос на вытягивание и запустив CI. Это означает, что исправление и косвенно информация об уязвимости становятся доступными для общественности. Это увеличивает риск того, что публикация исправления уязвимости будет невозможна из-за проблемы с CI. Чтобы снизить этот риск, перед публикацией исправления уязвимости необходимо выполнить следующие тесты локально и успешно:
npm run test (MongoDB)npm run test (Postgres)npm run madge:circular (циклические зависимости)npm run lint (Lint)npm run definitions (Parse Server options definitions)Текущее ограничение GitHub не позволяет настраивать сообщение коммита при слиянии запросов на вытягивание из частной ветки, созданной для исправления уязвимости системы безопасности. Наша система автоматизации выпуска требует определённого синтаксиса сообщения коммита, который поэтому не может быть соблюдён. Это запрещает следовать процессу, предложенному GitHub, который заключается в том, чтобы объединить запрос на вытягивание непосредственно из частной ветки в публичную ветку. Вместо этого после локального тестирования необходимо создать публичный запрос на вытягивание с исправлением кода, скопированным из частного запроса на вытягивание.
Это создаёт риск косвенного раскрытия уязвимости путём публикации запроса на вытягивание с исправлением, но исправление не может быть объединено из-за проблем с CI. Чтобы уменьшить этот риск, заголовок и описание запроса на вытягивание должны быть общими или нейтральными, не затрагивающими уязвимость и не предоставляющими никаких подробностей об уязвимости, пока запрос на вытягивание не будет успешно объединён.
package-lock.json должен регулярно удаляться и создаваться заново с помощью команды npm i. Недостаточно обновить файл с помощью автоматических запросов на безопасность (например, dependabot, snyk), которые могут создать несоответствия между подзависимостями зависимости и увеличить вероятность уязвимостей. Файл следует создавать заново один раз в цикл выпуска, который обычно составляет месяц.В то время как текущая основная версия публикуется в ветке release, версия долгосрочной поддержки (LTS) публикуется в ветке release-#.x.x, например release-4.x.x для ветки Parse Server 4.x LTS.
Следующие изменения вносятся в ветку alpha перед публикацией последней версии beta, которая в конечном итоге станет основным выпуском. Таким образом, изменения естественным образом распространяются по всем веткам и коду. Выпуск основной версии (ежегодный выпуск)
release-#.x.x на основе последнего тега версии в ветке release.build-release на основе ветки beta и создайте запрос на слияние с веткой release в качестве базовой.build-release с release. Учитывая, что будут внесены критические изменения, будет создан новый основной выпуск. В маловероятном случае, если между предыдущим основным выпуском и предстоящим выпуском не было критических изменений, необходимо вручную инициировать увеличение основной версии. См. документацию по платформе автоматизации выпуска для получения информации о том, как это сделать.release-#.x.x, полученную на шаге 1, в Snyk, чтобы Snyk открывал запросы на слияние для ветки LTS; удалите ранее существующую ветку LTS release-#.x.x из Snyk.Версионирование
Следующая система версионирования применяется начиная с Parse Server 5.0.0 и может не применяться к предыдущим выпускам.
Parse Server использует семантическое версионирование с оттенком календарного версионирования. Семантическое версионирование упрощает обновление Parse Server, поскольку критические изменения происходят только в основных выпусках. Календарное версионирование даёт дополнительное представление о возрасте выпуска Parse Server и позволяет осуществлять долгосрочную поддержку предыдущих основных выпусков.
Пример версии: 5.0.0-alpha.1
Синтаксис: [major].[minor].[patch]-[pre-release-label].[pre-release-increment]
— Версия major увеличивается при первом выпуске каждого года и может включать изменения, которые несовместимы с предыдущими версиями.
— Версия minor увеличивается в течение года и может включать новые функции или улучшения существующих функций, совместимые с предыдущими версиями.
— Версия patch увеличивается в течение года и может включать исправления ошибок, совместимые с предыдущими версиями.
— Метка предварительного выпуска pre-release-label является необязательной для предварительных версий, таких как:
— -alpha (вероятно, содержит ошибки, вероятно, изменения в функциях до выпуска)
— -beta (вероятно, содержит ошибки, без изменений в функциях до выпуска).
— [pre-release-increment] — это число, которое увеличивается с каждой новой версией предварительного выпуска.
Исключения:
— Версия major может увеличиваться в течение года в маловероятном случае, когда критическое изменение настолько срочно, что его нельзя отложить до следующего ежегодного выпуска. Примером может служить исправление уязвимости, приводящее к неизбежному критическому изменению. Однако требования безопасности зависят от приложения, и не каждая уязвимость может повлиять на каждое развёртывание в зависимости от используемых функций. Поэтому мы обычно предпочитаем объявлять устаревшими небезопасные функции и вносить критические изменения в соответствии с нашей политикой устаревания.
Этот проект придерживается Кодекса поведения Contributor Covenant. Участвуя в проекте, вы должны соблюдать этот кодекс.
Вы можете оставить комментарий после Вход в систему
Неприемлемый контент может быть отображен здесь и не будет показан на странице. Вы можете проверить и изменить его с помощью соответствующей функции редактирования.
Если вы подтверждаете, что содержание не содержит непристойной лексики/перенаправления на рекламу/насилия/вульгарной порнографии/нарушений/пиратства/ложного/незначительного или незаконного контента, связанного с национальными законами и предписаниями, вы можете нажать «Отправить» для подачи апелляции, и мы обработаем ее как можно скорее.
Опубликовать ( 0 )