Я работаю над сервисом + веб-приложение + мобильное приложение, где
- мобильное приложение используется для потребления контента
- создано открытым сообществом авторов в веб-приложении
- при этом все обслуживается сервером, на котором работает Nginx в Ubuntu (ну, некоторые запросы передаются через прокси на серверные серверы Nginx), но это деталь
Проблема, которую я хочу эффективно решить, связана с тем фактом, что контент может быть создан открытое сообщество - почти каждый может нажать несколько кнопок и начать процесс создания контента, в ответ на который сервер генерирует контент-заглушку в виде файла JSON для настройки авторами контента.
Теперь вот проблема: я хочу избежать траты серверного времени и дискового пространства на создание заглушки JSON-контента для авторов, которые начинают процесс, но никогда не выполняют его (перевод = зарегистрироваться, чтобы создать контент, а затем никогда не делать).
Другими словами, я хочу создавать заготовку JSON-контента для авторов только тогда, когда я уверен, что они действительно собираются приступить к процессу его настройки. В то же время я хочу убедиться, что мобильное приложение получает изящную ошибку 404 для содержимого, извлеченного из CDN, которое оно пытается получить через CDN.
Другими словами, есть два набора «потребителей» контента.
- Авторы контента, которые обычно запрашивают контент непосредственно с моих серверов через веб-приложение бэк-офиса, которое отображается в NGINX как `$http_reffer = https://example.com/backoffice'
- CDN, которая будет пытаться получить тот же контент из того же места в ответ на запросы мобильного приложения.
Ответы по умолчанию для отсутствующего контента:
- Авторы контента: Заглушка JSON генерируется и отправляется обратно
- CDN: Содержимого JSON-файла не существует, поэтому возвращается заголовок 404.
Решение, которое я имею в виду, находится в следующем блоке конфигурации Nginx.
расположение /cdn/appdata/content
{
add_header Access-Control-Allow-Origin *;
если ($http_referer ~* ^https://example.com/backoffice)
{
if (!-e $request_filename) {переписать ^/(.*)$ /pathto/stub-json-generator.php?$1 последним;}
}
} еще ??? /* верните существующий JSON или ответьте с кодом 404. Оба запроса к CDN
Время от времени я балуюсь конфигурацией Nginx, но не являюсь экспертом. Мой вопрос - это то, что я наметил достойный способ решения этой задачи, или мне нужно глубже вникать в сценарии Nginx через JS или Lua? Сценарии Lua требуют установки Open Resty, чего я хотел бы избежать, поскольку у меня уже настроен Nginx для работы с NChan и Dart, что затем мне пришлось бы делать снова и снова для Open Resty. Помимо этого, попытка доступа к Redis и Postgres из скрипта Lua приведет меня на незнакомую территорию.
Я мог бы просто удалить этот вопрос, но я оставляю его здесь со своим решением для всех, кто хочет сделать что-то подобное.
Решение на самом деле ослепительно простое и не является полностью проблемой конфигурации Nginx. Важно понимать, что Nginx работает поверх Ubuntu и теперь имеет способ различать настоящий папка и символическая ссылка. Итак, предположим, что мы сделали следующее
- Назначить папку
/путь/к/авторским данным символическая ссылка /путь/к/readercontent таким образом
ln -s /path/to/authordata /path/to/readercontent
Теперь настройте следующие блоки конфигурации Nginx.
местоположение /путь/к/авторским данным
{
add_header Access-Control-Allow-Origin *;
переписать ^(.*)$ /path/to/authordata/index.php?$1 последним;
}
расположение /путь/к/readercontent
{
add_header Access-Control-Allow-Origin *;
}
Без ведома друг друга эти два блока на самом деле обращаются к одной и той же папке Ubuntu.
Мы используем первый для доступа к данным автора для редактирования. Поскольку содержимое доставляется скриптом PHP, у нас есть возможность генерировать заглушки на ходу. Таким образом, не будет засоряющего сервер содержимого авторской заглушки, которое никогда не будет использоваться по умолчанию.
Мы используем последний, чтобы получить материалы для чтения в мобильное приложение через запрос на вытягивание CDN. Отсутствующий ресурс данных автора приведет к стандартному ответу 404. Заголовок CORS, который мог бы быть более конкретным, препятствует тому, чтобы CDN отбрасывал данные.
