Согласно странице цен на Quicksight, если вы создаете встроенную панель управления для Quicksight Reader , то вы платите 0,30 доллара США за сеанс за 30-минутный сеанс входа в систему для этого Reader.
Срок действия сеанса может быть установлен в параметре SessionLifetimeInMinutes API GetDashboardEmbedUrl и имеет верхнюю границу 600 минут (10 часов).
В качестве примера предположим, что вы установили SessionLifetimeInMinutes на 600 минут для своего пользователя Reader. Также предположим, что этот пользователь остается в системе и использует панель мониторинга в течение 10 часов непрерывно, тогда это будет равняться 20 сеансам использования (поскольку выставление счетов производится с шагом 30 минут). На первый взгляд может показаться, что при этом будет выставлен счет в размере 0,30 доллара США за сеанс * 20 фрагментов сеанса = 6 долларов США.
Однако, согласно странице с ценами, существует верхняя граница в 5 долларов США в месяц для каждого Читателя. Это означает, что этот Reader никогда не может превышать 5 долларов в месяц, независимо от того, сколько сеансов Quicksight (любой продолжительности) создано для них. Поэтому независимо от того, сколько раз вы вызываете GetDashboardEmbedUrl API для данного Reader, вы ограничены 5 долларами в месяц для этого пользователя.
Также можно использовать в отношении того, что составляет сеанс Reader (со страницы цен):
When does a Reader Session start and end?
A Reader Session starts with user-initiated action (e.g., login, dashboard load, page refresh, drill-down or filtering) and runs for next 30-minutes.
Keeping Amazon QuickSight open in a background browser window/tab does not result in active sessions until the Reader initiates action on page.
Но мое веб-приложение запросит новый URL-адрес для встраивания, когда пользователь перезапустит его (путем закрытия / повторного открытия вкладки / браузера). Означает ли это, что был создан новый сеанс пользователя и выставлен счет.
Я не уверен в этом на 100%, но да, я считаю, что обновление (или открытие / закрытие) вкладки приводит к новому сеансу для того же пользователя.
Сеанс чтения начинается с действия, инициированного пользователем (например, входа в систему, загрузки панели мониторинга, обновления страницы, детализации или фильтрации), и длится следующие 30 минут.
Вышеупомянутая выдержка со страницы цен. Таким образом, кажется, что обновление страницы (и, следовательно, еще один вызов GetDashboardEmbedUrl) запустит новый сеанс для пользователя.
Какой код авторизации упоминается в приведенном выше сообщении об ошибке?
Ответ API GetEmbedDashboardUrl - это объект JSON, который выглядит следующим образом:
{
"Status": 200,
"EmbedUrl": "https://us-east-1.quicksight.aws.amazon.com/embed/f4147cd0d4d_BLAH_BLAH_...",
"RequestId": "c15a7bad-629e-444a-b643-ff3142c9ae41"
}
Если вы внимательно посмотрите на EmbedUrl, помимо самого URL-адреса панели инструментов, есть еще следующие параметры строки запроса:
- isauthcode
- код
- удостоверение личности
- statePersistenceEnabled
- потенциально: другие параметры тоже
Параметр code (встроенный в embedUrl) - это код авторизации, о котором вы спрашивали.
Можно ли сохранить встроенный URL-адрес и повторно использовать его (до тех пор, пока длится сеанс пользователя), если тот же пользователь закрывает вкладку / браузер и снова открывает веб-приложение и панель управления (конечно, в том же браузере)?
Нет, это невозможно. Как сказано в ссылке, которой вы поделились:
The following rules apply to the combination of URL and authorization code:
- They must be used together.
- They can be used one time only.
- They are valid for 5 minutes after you run this command.
Таким образом, embedURL и связанный с ним код аутентификации можно использовать вместе только один раз. Имеет смысл, поскольку это предотвратит атаки повторного воспроизведения MITM среди других сценариев. Кроме того, я действительно пытался кэшировать ответ, а затем повторно использовать embedUrl в случае попадания в кеш, поскольку это улучшило бы взаимодействие с конечным пользователем. Но это не сработало - повтор embedUrl блокируется QuickSight, как упоминалось в их документе.
Есть комментарии по поводу сроков?
Это был наш опыт. GetDashboardEmbedUrl REST API для нашего приложения занимает около 5-7 секунд (us-east-1), а затем фактическое встраивание занимает еще 3-5 секунд. Не очень хорошо, но на данный момент я не вижу выхода из этого плохого пользовательского опыта.
person
nonbeing
schedule
03.06.2021
