Текущие данные запроса/пользователя в моделях в Scala Play! 2,5

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

В идеале я хотел бы использовать @RequestScoped Guice для внедрения одного и того же UserIdentity в мой запрос везде, где мне это нужно. Однако, насколько я могу судить, Play! Framework поддерживает только @Singleton и без области видимости. Таким образом, либо мы получим один и тот же UserIdentity для разных запросов, либо разные для каждой запрашиваемой модели/утилиты. И то, и другое не подходит по понятным причинам.

Есть ли способ использовать это поведение в Play 2.5?

Другие способы, которые я пробовал

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

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


person Nathan Edwards    schedule 07.05.2016    source источник
comment
Вы когда-нибудь находили решение для этого?   -  person pme    schedule 11.07.2018
comment
@pme В итоге я отправил свой класс UserIdentity как неявный val.   -  person Nathan Edwards    schedule 13.07.2018
comment
Спасибо за ответ - я так и думал или Guice Assigned. Я также попробовал, но пока не получил ответа: заголовок stackoverflow.com/questions/51281807/   -  person pme    schedule 14.07.2018


Ответы (1)


Ознакомьтесь с мой ответ на вопрос о перенаправлении запросов, где я привел пример получения текущего пользователя в каждом запросе.

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

person andyczerwonka    schedule 07.05.2016
comment
Моя проблема в том, что я хочу, чтобы пользовательские данные были в модели, а не в контроллере, что, по-видимому, и предлагает ваш ответ. - person Nathan Edwards; 07.05.2016
comment
Почему бы не передавать пользовательские данные в качестве параметра вашим моделям? - person marcospereira; 07.05.2016
comment
@marcospereira Проблема именно в этом — причина, по которой мы используем внедрение зависимостей. Каждый уровень метода должен будет передавать идентификатор вниз, пока мы, наконец, не достигнем метода, который действительно хочет его использовать. Это также означало бы, что я должен создать его экземпляр в контроллере, что я не обязательно хочу делать. В идеале я хочу, чтобы он вводился по мере необходимости. Я могу в конечном итоге передать его неявно, но я не думаю, что это идеально или идиоматично. - person Nathan Edwards; 07.05.2016
comment
Здесь нет никакой магии. Если вам нужен текущий пользователь где-то глубоко в вашей цепочке вызовов, вам нужно будет получать его там при каждом запросе. В зависимости от используемого вами метода аутентификации ваша стратегия будет меняться. Что неустранимо, так это то, что его нужно каким-то образом вводить, поэтому выбирайте любой метод, который вы предпочитаете. - person andyczerwonka; 07.05.2016