Basic HTTP Auth for S3 Buckets

The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:

Amazon S3 - это простое и очень полезное хранилище двоичных объектов (также известных как “файлы”). Чтобы его использовать, вы создаете там “ведро” с уникальным именем и загружаете свои объекты.

После этого AWS гарантирует, что ваш объект будет доступен для загрузки через их RESTful API.

Несколько лет назад AWS представили функцию S3, называемую хостинг статических веб-сайтов.

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

При использовании хостинга вам необходимо изменить запись CNAME в своем DNS так, чтобы она указывала на www.example.com.aws.amazon.com. После изменения записи DNS ваш статический веб-сайт будет доступен по адресу www.example.com, как обычно.

Однако, при использовании Amazon S3 невозможно защитить ваш веб-сайт, потому что контент является исключительно статическим. Это означает, что вы не можете иметь страницу входа на переднем плане. С помощью этой услуги вы можете либо сделать ваши объекты абсолютно общедоступными - чтобы любой мог их видеть онлайн, либо присвоить им права доступа - но только для пользователей, подключенных через RESTful API.

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

Протокол HTTP предлагает удобную функцию “базовой аутентификации”, которая не требует дополнительных страниц сайта.

Когда запрос HTTP поступает на сервер, он не передает содержимое, а отправляет ответ со статусом 401. Этот ответ означает буквально “Я не знаю, кто вы, пожалуйста, аутентифицируйтесь”.

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

Теперь браузер пытается снова получить ту же веб-страницу. Но на этот раз запрос HTTP содержит заголовок:

Вышеуказанное является всего лишь примером. В данном примере, закодированная в Base64 часть означает joe:secret, где joe - это имя пользователя, а secret - пароль, введенный пользователем.

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

Поскольку Amazon не предоставляет эту функцию, я решил создать простой веб-сервис, s3auth.com, который находится перед моими ведрами Amazon S3 и реализует механизм аутентификации и авторизации с помощью HTTP.

Вместо того чтобы делать мои объекты общедоступными, я делаю их приватными и указываю CNAME-запись на relay.s3auth.com. Затем HTTP-запросы от веб-браузеров поступают на мой сервер, подключаются к Amazon S3, извлекают мои объекты и доставляют их обратно в ответах HTTP.

Сервер реализует аутентификацию и авторизацию с использованием специального файла .htpasswd в корне моего ведра. Формат файла .htpasswd идентичен тому, который используется сервером Apache HTTP — один пользователь на строку. Каждая строка содержит имя пользователя и хэш-версию его пароля.

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

В целях конфиденциальности и удобства, я использую только OAuth2 для учетных записей пользователей. Это означает, что я не знаю, кто мои пользователи. У меня нет их имен или адресов электронной почты, только их номера учетных записей в Facebook, Google Plus или GitHub. Конечно же, я могу найти их имена, используя эти номера, но эта информация все равно является общедоступной.

Сервер реализован на Java6. Для его размещения я использую один сервер Amazon EC2 m1.small Ubuntu. В настоящее время сервер, кажется, работает правильно и стабильно.

Помимо аутентификации и авторизации, сервер s3auth.com может отображать списки страниц - как Apache HTTP Server. Если у вас есть коллекция объектов в вашем контейнере, но отсутствует файл index.html, Amazon S3 выдает результат “страница не найдена”. В свою очередь, мой сервер отображает список объектов в контейнере, когда нет файла index.html, и позволяет перемещаться вверх или вниз по одной папке.

Когда функция версионирования включена для вашего контейнера, вы можете просмотреть все версии любого объекта в браузере. Для этого просто добавьте ?all-versions в конец URL-адреса, чтобы отобразить список. Затем щелкните версию, чтобы сервер s3auth.com получил и отобразил ее.

Я создал эту службу в основном для себя, но, похоже, я не единственный с такими проблемами, описанными выше. В данный момент s3auth.com размещает более 300 доменов и отправляет более 10 Мб данных каждый час.

P.S. В этом посте объясняется, как s3auth.com может использоваться в качестве фронтэнда для вашего хранилища Maven: Как настроить частное хранилище Maven в Amazon S3.

Translated by ChatGPT gpt-3.5-turbo/42 on 2023-11-17 at 17:07

sixnines availability badge   GitHub stars