Как организовать приём файлов от клиентов без регистрации в вашем облаке

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

В Nextcloud для такого случая есть режим File drop. По документации Nextcloud, он разрешает загрузку в папку без просмотра файлов, которые там уже лежат (Nextcloud: File sharing). Вокруг этого режима и строится вся схема. Но сам режим решает только половину дела. Вторая половина — как устроены папки, на какой срок выдаётся ссылка, что происходит с большим файлом и кто потом разбирает принятое.

Одна папка — один адресат или один процесс

Самая частая ошибка — сделать одну общую папку «От клиентов» и раздать на неё одну ссылку всем. Даже если File drop скрывает содержимое, вы получаете свалку: файлы «скан.pdf», «договор (1).pdf» и «IMG_2041.jpg» от разных людей лежат вперемешку, а понять, кто что прислал, можно только по времени загрузки и догадкам.

Куда надёжнее выделять папку под конкретного адресата или конкретный процесс. Первый вариант — папка на клиента: «Приём / Клиент Иванов». Второй — папка на процесс: «Приём / Документы для оформления договора, март». Выбор зависит от того, что вам удобнее потом разбирать. Если с клиентом вы работаете годами и документы идут потоком, лучше папка клиента. Если у вас много разовых заявителей и каждая заявка живёт сама по себе, лучше папка заявки: после закрытия её целиком переносят в архив и ссылку отключают.

Заведите единое правило имени. Например: фамилия или название компании, затем номер заявки или месяц. Правило нужно не для красоты. Через полгода, когда кто-то спросит «а что присылал нам тот заказчик», поиск по имени папки даст ответ быстрее любых разбирательств.

Теперь о самом важном моменте — разделении клиентов. Допустим, у вас два клиента: Ирина и Павел. Каждому нужна своя ссылка, и ни один не должен увидеть то, что присылал другой, а тем более прежние загрузки самого себя. Это достигается двумя вещами одновременно:

• у каждого своя папка и своя публичная ссылка в режиме File drop — тогда Павел физически получает доступ только в «свою» папку, куда он может лишь класть;
• ссылка создана на конечную папку, а не на её родителя — иначе права, унаследованные сверху, могут оказаться шире, чем вы рассчитывали.

Если же вы выдали ссылку на общую папку с подпапками, а потом решили, что так проще, — получите ровно ту ситуацию, которой хотели избежать.

Загрузка без просмотра: как выглядит File drop для клиента

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

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

Обратите внимание на побочное следствие. Клиент не видит, что файл дошёл, кроме сообщения самой страницы о завершении загрузки. Он не может открыть папку и убедиться, что документ на месте. Поэтому нужен второй канал подтверждения: вы сами пишете «получили три файла, спасибо» или даёте клиенту понять, как выглядит успешная отправка. Без этого вы получите звонки «а вы точно видите?» — самый предсказуемый побочный эффект режима без просмотра.

И ещё один нюанс, о котором лучше помнить с самого начала. File drop не говорит вам, кто именно загрузил файл. Страница не требует входа, поэтому ссылка — это не удостоверение личности. Любой, у кого оказалась ссылка, может положить в папку что угодно. Если для вас важно, что документ прислал именно этот человек, личность придётся подтверждать другим способом: звонком, перепиской по известному адресу, сверкой с договором. Сама по себе загрузка по ссылке отправителя не идентифицирует.

Пароль, срок и роль администратора сервера

У публичной ссылки есть два управляемых ограничителя: пароль и срок действия. Оба описаны в документации Nextcloud (Nextcloud: File sharing). Срок при этом работает жёстко: когда он истекает, share отключается, и ссылка перестаёт принимать файлы.

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

Пароль отвечает на другой вопрос: «что будет, если ссылка попадёт не туда». Пересланное письмо, скриншот в общем чате, ссылка в истории браузера на рабочем компьютере — всё это обычные пути утечки адреса. Пароль, переданный отдельным каналом (ссылка по почте, пароль по телефону или в мессенджере), закрывает именно такие случаи. Но не стоит приписывать ему больше, чем он умеет. Пароль доказывает лишь то, что человек его знает. Принадлежность файлов конкретному клиенту он не удостоверяет.

Теперь про администратора. Права администратора сервера и права владельца папки — разные вещи, и путать их опасно в обе стороны. Владелец папки управляет ссылкой: включает File drop, ставит пароль и срок. Администратор сервера отвечает за то, какие вообще варианты ссылок разрешены, где физически лежат данные и какие лимиты стоят. Документация прямо говорит, что доступные опции шаринга зависят от настроек администратора. Следовательно, если у сотрудника в интерфейсе нет галочки «пароль обязателен» или нет самого File drop, это вопрос политики сервера, а не ошибка сотрудника.

Отдельно напомню про один соблазн: опцию «скрыть скачивание». Документация уточняет, что она лишь убирает элементы интерфейса и усложняет скачивание, но не является запретом (Nextcloud: File sharing). Для приёмной папки в режиме загрузки она и так не нужна, а в других сценариях защитой от копирования её считать нельзя.

Как проверить, кто реально видит папку

Перед тем как отправить ссылку клиенту, проверьте доступ к папке не только по ней самой. В карточке общего доступа Nextcloud есть раздел «Others with access» — он показывает доступ, полученный через родительскую общую папку. Документация подчёркивает: права нельзя оценивать только по текущему объекту (Nextcloud: File sharing).

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

Короткая проверка перед выдачей ссылки:

1. откройте свойства папки и посмотрите, кто имеет к ней доступ напрямую и через родителя;
2. убедитесь, что публичная ссылка создана именно на эту папку и в режиме загрузки;
3. откройте ссылку в приватном окне браузера, где вы не авторизованы, и убедитесь, что содержимого вы не видите;
4. загрузите тестовый файл и найдите его уже под своей учётной записью.

Четвёртый пункт заодно проверяет весь маршрут: файл, пришедший «снаружи», действительно оказывается там, где вы будете его искать.

Большой файл: где он застрянет

Пока клиент присылает паспортные сканы, никаких проблем не возникает. Трудности начинаются с видео осмотра, архива фотографий или выгрузки из учётной системы на несколько гигабайт. Здесь «лимит загрузки» оказывается не одним числом, а цепочкой звеньев. Документация Nextcloud говорит об этом прямо: ограничения зависят от способа передачи, веб-сервера, PHP и временного хранилища (Nextcloud: Uploading big files).

Разберём по звеньям, где может оборваться передача:

• веб-сервер может ограничивать размер тела запроса или время ожидания;
• PHP имеет собственные пределы, в том числе знаменитые upload_max_filesize и post_max_size;
• временное хранилище должно вместить файл на время приёма, до того как он окажется на своём месте;
• свободное место и квота получателя в конце пути тоже должны позволять принять файл.

Есть тонкость, которую часто упускают. По документации, клиент синхронизации передаёт файлы частями, и значения upload_max_filesize и post_max_size могут не применяться к WebDAV PUT и chunked-загрузкам так же, как к обычной форме (Nextcloud: Uploading big files). Для вас это значит следующее: проверять лимит нужно тем способом, которым будет пользоваться клиент. Если ваш сотрудник испытал загрузку через десктопный клиент и всё прошло, это ещё не доказывает, что обычная веб-страница по публичной ссылке примет тот же файл. А клиент по File drop чаще всего пользуется именно страницей в браузере.

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

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

Сколько временного места нужно на самом деле

Теперь расчёт, который чаще всего забывают. Документация Nextcloud отдельно подчёркивает, что временное место нужно учитывать для параллельных загрузок, а не только для одного максимального файла (Nextcloud: Uploading big files).

Возьмём условный пример: все числа ниже выдуманы для иллюстрации и должны быть заменены вашими. Пусть вы решили принимать файлы до 4 ГБ. В понедельник утром, когда приходит отчётность, одновременно загружают пятеро клиентов, и у троих файлы близки к максимуму, а у двоих — по 1 ГБ.

Проверка «лимит 4 ГБ, значит нужно 4 ГБ» дала бы ошибку в 3,5 раза. И это ещё без запаса: пока файл собирается во временном месте, а потом переносится на постоянное, на какое-то время нужны оба объёма — часть временного и уже занятое под данные. Поэтому честная формула для планирования выглядит так: число одновременных загрузок, умноженное на максимальный размер, плюс постоянное место под принятое, плюс запас на рост.

Отсюда прямая связь с выбором VPS. Если у вас совсем небольшой поток — несколько клиентов в неделю и документы по десятку мегабайт, — скромного тарифа хватит с запасом. Если же вы ждёте видео и архивы, диск начинает определять всё. В публичном предложении MAATRIX перечислены тарифы Ba (1 vCPU, 2 ГБ RAM, 40 ГБ NVMe), Uab (2 vCPU, 4 ГБ, 80 ГБ), Heka (4 vCPU, 8 ГБ, 160 ГБ), Maat (8 vCPU, 16 ГБ, 240 ГБ) и Djed (16 vCPU, 32 ГБ, 320 ГБ) (страница аренды VPS MAATRIX). Но ресурсы тарифа — это не обещание ёмкости: 40 ГБ диска не значат «40 ГБ под файлы клиентов», потому что часть займут система, само приложение, база и те же временные файлы. На условном примере выше пик в 14 ГБ уже забирает больше трети диска самого младшего тарифа, ещё до того как вы сохранили хоть один документ. Размер тарифа стоит определять по вашему пику параллельных загрузок и по тому, как быстро вы разбираете принятое, а не по средней нагрузке.

Для самого Nextcloud в каталоге MAATRIX заявлена установка вместе с VPS; точное состояние наличия и операционной системы проверяется в форме заказа. Доступ root у вас есть, а значит, лимиты веб-сервера и PHP вы можете настроить сами, без обращения к хостеру.

Что происходит с файлом после приёма

Принять файл — это начало, а не конец. Папка File drop по замыслу не место хранения. Это почтовый ящик в подъезде: письма в нём лежат, пока их не заберут. Если принятое остаётся там навсегда, через год вы получите архив без структуры и с неясными сроками хранения.

Разумный маршрут состоит из четырёх шагов.

1. Заметить. Кто-то должен узнать, что файл пришёл. Уведомления в Nextcloud настраиваются, но работают только если механизм доставки действительно подключён и настроен: почтовый сервер, учётные данные, проверка. Без этого не стоит рассчитывать, что письмо о загрузке придёт само. Если уведомление не настроено, договоритесь о ручной проверке по расписанию и закрепите, кто и когда открывает папки.
2. Проверить. Откройте файл и убедитесь, что это тот документ, который ожидался: читается, нужное количество страниц, нет подмены формата. Антивирусной проверки из самого факта File drop не следует. Если вам нужно сканировать вложения, это отдельный механизм, который надо поставить и настроить, и без него считать принятые файлы проверенными нельзя.
3. Переместить. Из приёмной папки файл переезжает туда, где с ним работают: в папку проекта, дела или клиента во внутренней структуре. После этого приёмная папка снова пуста и готова к следующей загрузке.
4. Удалить или закрыть. Когда процесс завершён, ссылку отключают или она истекает по сроку, а папку убирают в архив или удаляют, если хранить её больше незачем.

Закрепите ответственного. Не «отдел», а конкретного человека или конкретную роль на каждую приёмную папку. Рабочее правило: у каждой папки приёма есть имя ответственного в её названии или описании. Тогда вопрос «кто это заберёт» не повисает в воздухе.

Теперь о резервных копиях. Приёмные файлы — это те же данные Nextcloud, и в бэкап они попадают вместе со всем остальным. В документации Nextcloud в перечне резервируемых частей названы config, custom apps (если они есть), data, theme и база данных; там же рекомендовано хранить копии за пределами окружения самого Nextcloud (Nextcloud: Backup). Если файл клиента лежит только на этом сервере, то при потере диска пропадёт и он. Поэтому момент между приёмом и перемещением в рабочую структуру — самый уязвимый, и тем важнее не копить документы в приёмке. Автоматические резервные копии на стороне VPS не заявлены как часть тарифов, так что копирование нужно организовать самому.

При самом копировании учтите ещё одну особенность. Режим обслуживания (maintenance mode) блокирует сессии и новые входы, чтобы данные не менялись в процессе (Nextcloud: Backup). Для приёмных ссылок это значит, что клиент, который в этот момент попробует загрузить документ, может получить отказ. Если вы работаете с клиентами в разных часовых поясах, планируйте окно обслуживания и предупреждайте о нём заранее.

Две ссылки, два клиента, один порядок

Соберём всё на условном примере с Ириной и Павлом.

Вы создаёте две отдельные папки: «Приём / Иванова, договор март» и «Приём / Павлов, договор март». На каждую выдаёте собственную публичную ссылку в режиме File drop с паролем и сроком в десять дней. Пароль отправляете отдельным сообщением. Перед отправкой открываете обе ссылки в приватном окне: ни содержимого, ни соседней папки там нет. Заглядываете в «Others with access» и убеждаетесь, что родитель «Приём» не раздан лишним людям.

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

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

Если ваш бизнес устроен сложнее и вы раздумываете, держать ли всю инфраструктуру самим или арендовать у провайдера, полезно посмотреть, как похожий выбор разбирают для другой задачи: 1С на 12 клиентов — свой терминальный сервер против аренды в облаке. Принцип там тот же: сначала считаются реальные нагрузки, потом выбирается площадка.

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