2014-01-18 3 views
5

Я создаю приложение, которое будет размещено в Azure. В этом приложении пользователи смогут загружать собственный контент. Они также смогут настроить список других доверенных пользователей приложений, которые смогут читать их файлы. Я пытаюсь понять, как архитектовать хранилище.Лазурное хранилище: общая подпись доступа для нескольких контейнеров?

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

Могу ли я использовать одну общую подпись доступа (или политику сохраненного доступа), чтобы предоставить пользователю доступ к нескольким контейнерам? Я нашел одну часть информации, которую я считаю очень актуальный:

http://msdn.microsoft.com/en-us/library/windowsazure/ee393341.aspx 

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

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

Спасибо за любые предложения ... -Бно

ответ

8

Так как вы собираетесь иметь контейнер для каждого пользователя (на данный момент я приравнять пользователь с тем, что вы назвали приложение идентификатора пользователя), что означает, что вы У вас будет учетная запись хранилища, которая может содержать множество разных контейнеров для многих пользователей. Если вы хотите, чтобы приложение имело возможность загружать только один конкретный контейнер, в то время как чтение из многих двух вариантов приходит на ум.

Первый: создайте API, который живет где-то, который обрабатывает все запросы. За API ваш код будет иметь полный доступ ко всей учетной записи хранилища, поэтому ваша бизнес-логика определит, что они делают и не имеют доступа. Поверхность этого заключается в том, что вам вообще не нужно создавать сигнатуры общего доступа (SAS). Ваше приложение знает, как разговаривать с API. Вы даже можете комбинировать данные, которые они могут видеть в этом сводке контента, делая параллельные вызовы для получения содержимого из различных контейнеров из одного вызова из приложения. Недостатком является то, что теперь у вас есть эта служба API, которая должна бронировать ВСЕ эти вызовы. Вам все равно понадобится служба API для генерации SAS, если вы идете по этому маршруту, но это было бы необходимо только для создания SAS, и клиентские приложения будут делать вызовы напрямую с помощью службы хранения Windows Azure с нагрузкой, которая уменьшит ресурсы вам действительно нужно.

Во-вторых: Идите по маршруту SAS и создайте SAS по мере необходимости, но это будет немного сложно.

На каждый контейнер можно создать до пяти политик сохраненного доступа. Для одного из этих пяти вы создаете одну политику для «владельца» контейнера, которая дает им разрешения на чтение и запись. Теперь, поскольку вы разрешаете людям давать разрешения на чтение другим людям, вы нажимаете на ограничение количества политик, если вы не повторно используете одну и ту же политику для чтения, но тогда вы не сможете отменить ее, если пользователь удалит кого-либо из своих «доверенный» список читателей.Например, если я предоставил разрешения как для Боба, так и для Джеймса для моего контейнера, и они оба получили копию Read SAS, если мне нужно было удалить Боба, мне пришлось бы отменить прочитанную политику, которую они поделили, и переиздать новый Read SAS к Джеймсу. На самом деле это не так уж и плохо, поскольку приложение может обнаружить, когда у него больше нет разрешений и просят обновить SAS.

В любом случае вы все еще хотите, чтобы политика была короткой. Если бы я удалил Боб из моих доверенных читателей, я бы очень хотел, чтобы он немедленно отрезал его. Это означает, что вы вернетесь, чтобы получить обновленную версию SAS и воссоздать подписанную подпись доступа, которая снижает полезность подписанных политик доступа. Это зависит от вашего живота от того, как долго вы планируете позволить политике жить и как быстро вы хотите, чтобы кто-то отрезал, если они были «ненадежны».

Теперь лучшим вариантом может быть то, что вы создаете Ad-hoc-сигнатуры. Вы можете иметь столько подписей Ad-hoc, сколько хотите, но их нельзя отменить и может длиться максимум один час. Поскольку вы сделаете их недолговечными, длина или отсутствие отзыва не должны быть проблемой. Переход по этому маршруту будет означать, что вы должны вернуть приложение, чтобы получить их по мере необходимости, но, учитывая то, о чем я упоминал выше, когда кто-то был удален, и вы хотите, чтобы SAS закончилось, это может быть неважным. Как вы уже указали, это увеличивает сложность вещей, потому что вы генерируете множество SAS; однако, если вы являетесь ad-hoc, вам не нужно их отслеживать.

Если вы собираетесь ехать по маршруту SAS, я бы предположил, что ваш API будет генерировать ad-hoc при необходимости. Они не должны длиться более нескольких минут, так как у людей может быть разрешение на удаление контейнера, и все, что вы пытаетесь сделать, это уменьшить нагрузку на размещенную службу для фактического выполнения загрузки и загрузки. Опять же, вся логика обработки контейнеров, которые кто-то может видеть, все еще находится в вашей службе API, и приложения просто получают подписи, которые они могут использовать в течение небольших периодов времени.

+0

Благодарим вас за подробный, продуманный ответ. Я буду перечитывать это несколько раз завтра, я уверен! – BenjiFB

Смежные вопросы