Middlewares' stack order

[devilicecream]

The default order of the middlewares' stack is (ignoring the TW middleware and the debugger):

Request > RegistryManager > Authentication > Caching > Sessions > Router > TGApp > Response

With this configuration, the thread local context is not available through the RegistryManager, Authentication, Caching, Sessions and Router middlewares, since the above is only generated by the TGApp.setup_app_env() method.

My problem

I'm experiencing this issue while trying to implement caching for my application's authentication process, which is also related to #20.

Having the context generation this deep in the request stack implies that even moving the Caching middleware before the Authentication middleware, I'm not able to use a CacheManager object registered on the Registry, thus eventually leading to possible problems with load peaks.

Wouldn't be better to organize the stack this way?

Request > RegistryManager > Context (new middleware that only generates the request context) > Caching > Authentication > Sessions > Router > TGApp > Response

[amol-]

environ contains the cache object before it gets pushed into the context. You will have to change the order of the middlewares by the way to make it available before the Auth.

20 has never been tackled as since the introduction of the TGAuthMetadata it is actually pretty straightforward to use the get_user method to retrieve everything from a cache and store them in identtiy thus making the other two methods a noop

[devilicecream]

Yes, although I noticed that to change the order of the Auth and Cache middlewares is sort of painful, since the Cache middleware is attached with the _add_coremiddlewares method. Wouldn't be simpler to put an option in the app_cfg to allow changes in the middlewares' stack order?

Regarding #20, what you say works only with a stateful authentication. In case of a statless one, my usual approach is to validate the authentication data, making queries, in the Authenticator plugin. Probably would be actually better to only actually make queries in the _TGAuthMetadata.getuser() method as you say, but still that needs the cache manager to be created before the authentication middleware handles the request.

[devilicecream]

Also, the request environ is not actually passed to the _TGAuthMetadata.getuser() method, meaning that, without a context, the only way I see to get the cache manager is to include the environ in the identity object.

[amol-]

As In TG2.3.5 most middleware have actually been moved to application wrappers this has been tackled in documentation in a way compatible with both current middleware stack and upcoming app wrappers: https://github.com/TurboGears/tg2docs/commit/62140a3ad1da03cf4908e0a9e21935fd27eb3a29