Restic: Серверная часть хранилища: Amazon Cloud Drive

Только что подумал о том же.

Я могу посмотреть на это, как только # 21 будет на месте - загрузка без сжатия кажется пустой тратой полосы пропускания.

Это зависит от вашего варианта использования;)

Я нашел некоторое доказательство концептуального кода: http://sprunge.us/fdQF — он требует, чтобы токен oauth был в /tmp/token.json, но, похоже, работает для меня.

Мотивированные люди могут превратить это в чистый бэкэнд для ACD :).

+1 от меня :)
Я скомпилировал бэкенд, найденный @stapelberg , и он действительно работает и использует код из rclone.

+1 тоже
Я пытаюсь использовать Restic + acd_cli (клиент FUSE python для ACD), но пока это очень ненадежно: некоторые операции ведут себя не так, как ожидалось (усечение файла, переименование), и в результате Restic случайно паникует.
Работающая серверная часть хранилища ACD могла бы удивить.

В настоящее время я переделываю интерфейс для бэкендов, это включает в себя радикальное упрощение. Это в основном сделано, но еще не объединено. План см. №383, PR №395.

После этого будет намного проще внедрять новые бэкенды.

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

Вы случайно не знаете, есть ли тестовый сервис для ACD, который мы можем использовать для тестов?

Насколько мне известно, тестового экземпляра для ACD нет. Здесь нет упоминания о такой вещи: https://developer.amazon.com/public/apis/experience/cloud-drive/content/restful-api

Но проект https://github.com/ncw/rclone уже создал серверную часть ACD. Кажется, что его можно использовать повторно, о чем свидетельствует доказательство концепции, предоставленное @stapelberg .

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

Я не знаю, как @ fd0 видит будущее Restic, но было бы логично сосредоточить проект на интеллектуальном резервном копировании вместо того, чтобы повторно реализовывать тонны удаленных файловых систем одну за другой. Кроме того, обе лицензии проекта совместимы.
Это также решило бы проблемы с тем, как тестировать все эти бэкэнды.

@klauspost была вашей идеей создать оболочку вокруг rclone/fs/fs.go? Выполнимо ли это без тесной связи с внутренней логикой rclone?

Каждый бэкенд реализует интерфейс fs.Fs. Каждый файл представлен как fs.Object .

Должно быть довольно легко создать restic-бэкенд, использующий файловую систему + папку rclone, при условии, что он уже настроен в конфигурации rclone.

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

Я предполагаю, что для restic его должно быть легко настроить и использовать с различными подходящими бэкендами. Это включает (на мой взгляд) только одно место для настройки, например, серверных частей. Возможно, это возможно с помощью rcclone или, по крайней мере, части их кода. Интерфейс выглядит подходящим для использования с restic.

Я пообещал вознаграждение в размере 5 долларов за эту функцию.

Некоторые мысли:

• Amazon Cloud Drive использует AWS S3 / CloudFront в качестве серверной части. Запросы GET всегда перенаправляются с заголовком Location в Cloudfront. Таким образом, вы можете использовать заголовок Range для запроса только части файла пакета, поскольку это требуется для нового внутреннего API. См.: http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RangeGETs.html .
• Вы можете начать с интеграции go-acd . Это библиотека, которую использует rclone.

в случае, если приоритет данного FR зависит от народного голосования: +1

👍

👍

Да пожалуйста 👍

Как насчет того, чтобы добавить еще несколько наград к этой функции?

См.: https://www.bountysource.com/issues/23684796-storage-backend-amazon-cloud-drive .

Награда теперь составляет 35 долларов США: https://www.bountysource.com/issues/23684796-storage-backend-amazon-cloud-drive .

Эй, спасибо за ваш интерес к restic в целом и этому бэкенду в частности.

Просто чтобы сообщить вам, что здесь блокирует: я не знаю, как обращаться со сторонними веб-сервисами. Для серверных частей local и sftp у нас есть обширные тесты, которые выполняются для каждого push/PR в рамках тестов CI на Travis. Это также верно для бэкэнда s3 , там мы используем локальный экземпляр сервера Minio s3, из-за этого я обнаружил несколько ошибок в клиентской библиотеке minio, которую мы используем в s3 бэкенд.

Как мы можем запускать тесты CI для серверных реализаций, которым требуется сторонняя служба? Есть ли, например, тестовая служба для ACD, которую мы могли бы использовать? А может просто взять проверенный код из других проектов типа rclone ?

Одним из решений может быть регистрация учетной записи в Amazon, добавление ее в белый список для API Cloud Drive, а затем использование ее для тестов CI? Недостатком является то, что такой тест зависит от доступности Cloud Drive, но я думаю, мы можем подождать час или около того, прежде чем объединять PR? :)

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

Когда мы добавим больше серверных частей для других сервисов, произойдет следующее:

• Количество зависимых сервисов для запуска тестов CI растет
• Для каждого бэкэнда нам понадобится тестовая учетная запись для использования в тестах.
• Эта тестовая учетная запись должна разрешать параллельные подключения, поскольку тесты (например, для PR) выполняются параллельно.

Я ничего не забыл?

Ваш список выглядит хорошо. Конечно, есть и другие эффекты, но я не уверен, подходят ли они для вопроса, на который вы пытаетесь ответить:

• Больше бэкэндов означает, что изменения, затрагивающие API бэкендов, становятся более сложными (необходимо обновить больше кода, протестировать больше кода).
• Людям, которые хотят запускать тесты локально, необходимо создать тестовую учетную запись или использовать собственную учетную запись.
• Больше бэкэндов делает restic более привлекательным для большего количества людей :).

Эта тестовая учетная запись должна разрешать параллельные подключения, поскольку тесты (например, для PR) выполняются параллельно.

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

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

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

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

Но я предлагаю пересечь этот мост, когда доберемся туда :).

Я пытался использовать ACD с restic (через Fuse), и система по-прежнему надежна (те же ошибки, что и kisscool). Я попробовал rClone, чтобы проверить их бэкенд, и проблем не возникло.

Но мне не нравится rClone (снимки...).

Вывод: +1 за собственный бэкэнд ACD!

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

Написание бэкенда — не такая уж сложная часть, здесь еще не хватает хорошего пользовательского интерфейса для настройки доступа к сервису. Каков рабочий процесс для получения токена oauth для ACD? Что нужно сделать пользователю для доступа к ACD через API?

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

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

Мне нужно проверить, как rclone автоматизирует этот процесс для тестирования, если он вообще это делает.

Да, тестирование — это отдельная история. Как мы запускаем тесты CI для этих серверных частей? Пожалуйста, не поймите меня неправильно, я бы хотел добавить облачные серверные части, но для этого нам нужна четкая стратегия.

Для настройки я также могу представить себе процесс на основе CLI, в котором restic печатает инструкции для пользователя. Я не очень хорошо знаком с процессом на данный момент, это вообще возможно?

Как вы думаете?

Идея 1 - Просто используйте rclone

Как насчет простой интеграции с rclone? Что-то вроде идеи типа «философии Unix», вы по-прежнему отлично делаете резервные копии, они по-прежнему хороши в облачном копировании, а пользователи получают лучшее из обоих миров.

Мне нужно посмотреть, что дает их API, если он существует, но поскольку мы оставляем конфигурацию исключительно для rclone (пользователи будут использовать rclone для добавления своих облачных учетных записей, а затем настроят restic для «использования rclone»), вы бы добавить гораздо меньше сложности в restic.

Идея 2. Как могли бы выглядеть тесты, если бы мы пошли по маршруту веб-сервера

Я предварю это, сказав, что я не читал документы для ACD, но я реализовал некоторые базовые вещи oauth в прошлом.

Если бы мы реализовали веб-сервер, мы могли бы просто протестировать следующее:

• Отвечает ли веб-сервер на правильных портах/адресах
• Когда я ПОЛУЧАЮ маршрут /, содержит ли он то, что я ожидаю (перенаправление, текст, который мы туда помещаем, и т. д.)
• Если я издеваюсь над ответом, который должен был прийти от Amazon (нужно больше подумать о том, как это сделать правильно), как он себя ведет?
• Еще нужно подумать: какие-то статические учетные данные для «тестирования», чтобы протестировать API. Сначала мне нужно посмотреть, как вы тестируете другие сервисы.

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

Извините, что замазал ваш ответ, немного набрал свой, прежде чем увидел ваш!

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

Я предполагаю, что процесс, вероятно, будет примерно таким, а это... опять же, просто rclone. Я ссылаюсь на нее снова и снова только потому, что это единственная программа, которая делает то, о чем мы говорим, достаточно хорошо.

Начать:

Затем настройте ACD:

Использование автоконфигурации (без головы)

Он очень быстро открыл локальный веб-сервер в моем браузере, который сразу же перенаправил на Amazon для входа в систему, и как только я вошел в систему, он связался с приложением CLI, создав:

Это в моем браузере:

и это, в моей командной строке
(60% учетных данных находятся в правой части моего экрана, за пределами скриншота, я не думаю, что это угроза безопасности, ха-ха)

Затем я сохраняю его, и теперь его можно использовать в программе.

Если я выберу другой вариант, мне просто предложат сделать следующее:

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

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

Мне интересно: зачем вообще нужен веб-сервер? Этот процесс работает для машины типа «рабочая станция», но не для сервера (где нет браузера). Рабочий процесс, используемый rclone, описан здесь: http://rclone.org/remote_setup/

Я не знаю, зачем нам для этого нужен веб-сервер, но я еще не реализовал рабочий процесс входа на основе oauth.

Нам также понадобится файл конфигурации для хранения токена, настроенного для удаленного доступа, но это еще не сделано.

Насколько я понимаю, данные oauth предоставляются пользователю с использованием данных GET при перенаправлении.

Посмотрите на URL-адрес на моем снимке экрана браузера. Это было размещено там Amazon. После того, как я нажал на вход в свой облачный диск Amazon, он сразу же перенаправил меня на этот URL-адрес 127.0.0.1.

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

Если я прав, то из этого следует, что вы должны запустить свой собственный веб-сервер, чтобы предоставить страницу для перенаправления на amazon, и страницу для обработки перенаправления с amazon, и это должно быть доступно через веб-браузер.

Что касается файла конфигурации, я думаю, все, что нам нужно, это файл, который находится в папке по умолчанию (~/.restic.conf), но может быть настроен с помощью флага или переменной среды. Я думаю, что это немного грязно, но это единственное жизнеспособное решение, прозрачное для обычного пользователя, но мощное для тех, кто хочет сделать это «по-своему».

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

Нам нужно:

• иметь файл конфигурации для хранения токенов аутентификации
• иметь «экземпляры» бэкэндов, например что-то под названием my_amazon_account , которое представляет собой бэкэнд ACD, настроенный с токеном входа, чтобы пользователи могли запускать restic --repo my_amazon_account:/foo/bar/dir ...
• иметь рабочий процесс для создания этих токенов входа
• зарегистрировать идентификатор клиента и секрет для использования с restic и скрыть его в исходном коде (аналогично тому, что делает rclone )

Что-нибудь еще, что мне здесь не хватает?

Я думаю, что вы получили основные вещи, обрисованные в общих чертах там.

Хотели бы вы переместить все текущие бэкенды в единую абстракцию, поддерживающую это, или вся эта система стала бы «облачным» бэкендом в текущем понимании бэкенда (который сам настраивается через специальные команды restic)?

Каждый экземпляр облачной серверной части (Google Drive, OneDrive, Amazon Cloud Drive, S3?) содержит следующие компоненты:

• Дополнительно: механизм авторизации
• Необязательно: произвольное постоянное состояние, обычно связанное с авторизацией, но должно поддерживать другие вещи. Это будет записано restic в файл для каждого экземпляра бэкэнда.
• Протокол для связи (т.е. интерфейс/API)

и, возможно, что-то еще, что мне не хватает

Текущая абстракция, судя по моему быстрому прочтению, относится только к последней вещи. Я думаю, что это довольно умный способ обработки бэкендов, если вы хотите немного его переделать.

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

• Иметь рабочий процесс для обновления токенов аутентификации (если срок их действия истекает, и провайдер предоставляет токен обновления, который должен храниться рядом с токеном аутентификации в вашей точке 1)

Вот некоторые сведения о внедрении секрета клиента в приложения с открытым исходным кодом: http://stackoverflow.com/a/28109307

Насколько я понимаю проблема: вам не разрешено встраивать секрет клиента в приложение с открытым исходным кодом. rclone использует некоторую запутанность, чтобы скрыть то, что они встраивают.

Я сомневаюсь, что встраивание статического идентификатора/секрета клиента в исходный код restic является хорошей идеей. С другой стороны, заставить пользователя самостоятельно зарегистрировать приложение сложно.

В этой статье описывается, как использовать oauth2 с Go: https://jacobmartins.com/2016/02/29/getting-started-with-oauth2-in-go/

Я сомневаюсь, что встраивание статического идентификатора/секрета клиента в исходный код restic является хорошей идеей.

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

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

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

Проблема здесь в том, что кому-то нужно прописать clientID, например мне. Если я использую свою обычную учетную запись Amazon (или, что еще хуже, свою учетную запись Google) и «нарушу» TOS для службы, опубликовав секрет клиента, они могут закрыть мою учетную запись. Это не то, чем я собираюсь рисковать.

Другая проблема заключается в том, что после изменения (или отзыва) секрета клиента мы остаемся со старыми версиями restic, например, в стабильной версии Debian, которые не могут взаимодействовать со службой из-за жестко запрограммированного (и теперь недействительного) секрета клиента. Это происходит даже в том случае, если доступ к сервису вскоре после этого восстановится, но секрет клиента изменится.

Я думал о возможных решениях и нашел только два:

• Живите с риском и просто поместите секрет клиента в источник
• Создавайте Restic таким образом, чтобы пользователям приходилось регистрировать свой собственный идентификатор клиента и секрет клиента с помощью приятного пользовательского интерфейса, сводящего к минимуму хлопоты.

В настоящее время я за второй вариант, нам все равно нужен пользовательский интерфейс для токена oauth. Как вы думаете?

Если я использую свою обычную учетную запись Amazon [...]

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

Интересная идея, у вас есть подсказка, к кому обратиться в Amazon?

Для Microsoft OneDrive он сказал, что ни с кем не связывался: https://github.com/ncw/rclone/issues/372

Я знаю, что @breunigs не повезло с его серверной частью дублирующего облачного диска Amazon — они не дали бы ему никаких исключений из ограничения скорости, насколько мне известно.

Я прочитал только последние несколько комментариев, поэтому, пожалуйста, простите меня, если эта информация не нужна:

• rclone реализует веб-сервер поверх него, предлагая удаленную настройку, где вы копируете URL-адрес. Наличие локального веб-сервера просто удобнее
• если вы хотите внести в белый список любую цель перенаправления в Amazon, она должна находиться на компьютере с http — ссылка на URL-адреса http недопустима. Единственным исключением является локальный хост. Итак, для удаленной настройки вы можете либо перенаправить пользователя на пустую страницу и надеяться, что он поймет, что ему нужно делать, либо разместить какую-то страницу с инструкциями. Я добавил https://breunig.xyz/duplicity/copy.html для дублирования, поскольку у него еще нет инфраструктуры https. Amazon добавит все детали в строку запроса, так что вы можете обойтись без создания статической страницы.
• Вам нужна учетная запись разработчика Amazon. Я полагаю, вы можете использовать свои существующие учетные данные для входа, но вы также можете создать новый.
• Существует процесс, в котором вы регистрируете свое приложение, а затем на более позднем этапе вы можете создать профиль безопасности для указанного приложения. Этот процесс очень сбивает с толку из-за ужасного UX, но он должен работать без участия человека от Amazon. (Примечание: по приложению они обычно относятся к «мобильным приложениям», но не всегда. Нажмите немного)
• Каковы ограничения, неясно, Amazon не говорит. Понятно, что есть несколько этапов: на пользователя, на конечную точку API, на учетные данные.
• Если вам нужны производственные ограничения, отправьте электронное письмо с «подробностями» на адрес [email protected]. Используйте крупный почтовый сервер, иначе они пометят вас как спам, и потребуется месяц или два, пока какая-нибудь бедняга не просмотрит весь их спам.

Кроме того, последний совет: прочитайте обходные пути rclone для Amazon Drive. API содержит множество недокументированных подводных камней «консистентности в конечном итоге». Он даже делает все возможное, чтобы кэшировать устаревший ответ, который он вам дал, так что вам придется ждать еще дольше, если вы были слишком поспешны с самого начала. Это помимо того, что сообщает об ошибках, когда их нет, нужно просто подождать.

ХТХ,
Стефан

Спасибо за информацию!

Просто выкидываю что-то там:

Что значит убираем все (кроме локальных и REST) ​​бэкенды с restic и втыкаем их в restic/rest-server?

Это позволяет restic сосредоточиться на правильном выполнении резервного копирования, а реализация файловой системы выполняется на rest-сервере.
Это также оставляет restic только с одним API-интерфейсом для поддержки.

Это не решает проблему тестирования, но, безусловно, поможет сохранить исходный код Restic чистым/сфокусированным, и будет проще вносить изменения API внутри Restic.

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

Интерфейс внутреннего API долгое время был стабильным, затем недавно изменился и снова будет стабильным. Интерфейс уже довольно маленький.

Мы должны попытаться как можно скорее перевести бэкенды в restic (включая надлежащие тесты CI), это ИМХО единственный способ убедиться, что они работают.

В случае серверной части Amazon ACD нам нужно сначала ответить на нерешенные вопросы.

В Руководстве разработчика Amazon для Amazon Drive (как это называется в наши дни) говорится, что:

Что нельзя строить

[...]

• Не создавайте приложения, которые шифруют данные клиентов

Я считаю, что Amazon Drive не является подходящей платформой для безопасного хранения зашифрованных резервных копий.

Интересно. Это должно быть новое дополнение, так как это определенно было не так, когда поддержка ACD была добавлена ​​​​в Arq.

Кажется, что ACD не является реальным вариантом хранения.

Действительно, добавление за последний год не было указано год назад: http://web.archive.org/web/20160322034250/https://developer.amazon.com/public/apis/experience/cloud-drive/ содержание/руководство разработчика

С тех пор Amazon разъяснила это в https://forums.developer.amazon.com/questions/54909/impact-of-dont-encrypt-customer-data-part-of-drive.html :

Что, если клиент решит зашифровать свои данные?
Они могут это сделать, и это нормально.

Таким образом, restic и другие приложения должны быть хорошими.

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

Стеффен

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

Я обратился в поддержку Arq Backup. Они все шифруют и говорят, что их приложение одобрено Amazon и не стоит волноваться.

Я не уверен, что Amazon пытается сказать. Но кажется, что сейчас оценивают каждый случай по мере поступления.

Не уверен, что кто-нибудь знает о недавней драме ACD с acd_cli и rclone, но TL; DR ситуации заключается в том, что у них был отозван доступ к API ACD из-за нарушений TOS. Их усилиям по восстановлению доступа к API, по-видимому, мешает тот факт, что Amazon перестала принимать новые сторонние приложения для ACD. Я предполагаю, что это последнее откровение останавливает любую поддержку Restic ACD, если только проект еще не получил доступ к ACD API.

Доступ к API acd_cli был отозван из-за проблемы безопасности с их приложением oauth, а не из-за нарушения TOS. Проблема была исправлена , и Amazon восстановил свой ключ. Хотя это не по теме этого проекта.

Доступ к новому API ACD в настоящее время закрыт .

Спасибо, что разместили это здесь, я не знал об этом. У меня были сомнения по внедрению ACD, и, похоже, Amazon действительно не любил секреты в коде программы с открытым исходным кодом: за это был забанен rclone: ​​https://forum.rclone.org/t/rclone-has-been-banned -с-амазон-драйв/2314

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

Поскольку Amazon все равно не принимает новых клиентов, я пока закрываю этот вопрос. Спасибо!