Since Play 2.4, the use of play.api.Application and play.api.Cache is deprecated and not recommended.
play.api.Cache singleton should be replaced with CacheApi and play.api.Application with Configuration/Environment.
To minimize the change, I think It's reasonable to add fields of CacheApi/Environment to AuthConfig trait. But it is not always the case for CacheApi. CacheApi is used only when CacheIdContainer is used as IdContainer. It is already discussed in https://github.com/t2v/play2-auth/issues/155. So I added idContainer field instead.
As for play.api.Environment which is the substitute of play.api.Application, I can say the same thing as CacheApi. It is used for only when CookieTokenAccessor.
However, should I added a tokenAccessor field to AuthConfig instead of Environment? It's a little difficult but I don't think it's necessary because Environment is also in AsyncAuth and much more commonly used than CacheApi in Play app.
Since Play 2.4, the use of
play.api.Application
andplay.api.Cache
is deprecated and not recommended.play.api.Cache
singleton should be replaced withCacheApi
andplay.api.Application
withConfiguration/Environment
.To minimize the change, I think It's reasonable to add fields of
CacheApi/Environment
toAuthConfig
trait. But it is not always the case forCacheApi
.CacheApi
is used only whenCacheIdContainer
is used asIdContainer
. It is already discussed in https://github.com/t2v/play2-auth/issues/155. So I addedidContainer
field instead.As for
play.api.Environment
which is the substitute ofplay.api.Application
, I can say the same thing asCacheApi
. It is used for only whenCookieTokenAccessor
. However, should I added a tokenAccessor field to AuthConfig instead of Environment? It's a little difficult but I don't think it's necessary becauseEnvironment
is also inAsyncAuth
and much more commonly used thanCacheApi
in Play app.