Best practices over how to store request attributes?

[bakura10]

Hi everyone,

I'm not sure if this fit more Zend\Expressive or Zend\Stratigility or Zend\Diactoros.

I find the pre_routing very interesting, as it allows to attach a middleware that could do various authentication work, and returning early if authentication does not match.

Actually, while refactoring ZfrOAuth2 to take advantage of middlewares, here is how it worked: https://github.com/zf-fr/zfr-oauth2-server/blob/middleware/src/Server/ResourceServerMiddleware.php#L57

As you can see, someone can attach this middleware, that will automatically inspecting the incomign request, doing the OAuth token check, and return a 401 if there are error. Then, it sets the token as part of the request: https://github.com/zf-fr/zfr-oauth2-server/blob/middleware/src/Server/ResourceServerMiddleware.php#L66

Next middlewares could therefore inspect the request, find the oauth_token and do more advanced validation. This actually completely remove the need for Zend\Authentication.

The issue is the naming. Should we encourage, as part of Expressive\Stratigility, best practices over how people should store attributes in order to not conflict with router attributes?

I thought of a simple scheme, like package:variable, in this case it would be zfr_oauth2:oauth_token.

What do oyu think?

[codeliner]

Problem: The next middleware would depend on your middleware but is maybe only interested in the oauth_token not that it was set by zfr_oauth2 ;)

Btw. I'm looking forward to the oauth2 integration. Great that you work on it :+1:

[bakura10]

Sure.

I'm just afraid if another middleware would also store something as "oauth_token" and then override what was set by my library. Having said that, it's true that it would be rather strange to use two libraries for handling the same thing.

PS: the code is nearly ready, the missing stuff is people trying it: https://github.com/zf-fr/zfr-oauth2-server/pull/35 :D

[danizord]

@bakura10 do it ZF style, config all ze things :P

[codeliner]

PS: the code is nearly ready, the missing stuff is people trying it: zf-fr/zfr-oauth2-server#35 :D

Good to know :smile: I hope I can find some time at the weekend to integrate zfr-oauth2 into our zend-expressive meets prooph example application. We need it as precondition to add some kind of identity to the application and activate our new ZfcRbac-MessageBus-Guard ;)

:+1: for the config option suggested by @danizord at least if you set oauth_token as default

[bakura10]

Awesome. Not everything is done yet (mostly the factories where I'm unsure how to integrate with doctrine yet). But feel free to contribute.

Regarding zfcrbac: https://github.com/ZF-Commons/zfc-rbac/issues/307

Envoyé de mon iPhone

Le 22 sept. 2015 à 19:37, Alexander Miertsch notifications@github.com a écrit :

PS: the code is nearly ready, the missing stuff is people trying it: zf-fr/zfr-oauth2-server#35 :D

Good to know I hope I can find some time at the weekend to integrate zfr-oauth2 into our zend-expressive meets prooph example application. We need it as precondition to add some kind of identity to the application and activate our new ZfcRbac-MessageBus-Guard ;)

for the config option suggested by @danizord at least if you set oauth_token as default

— Reply to this email directly or view it on GitHub.

[weierophinney]

My inclination is:

• For things like oauth, the liklihood of having multiple middleware adding those attributes is slim to none.
• Your middleware that depends on such values should allow configuring which attribute key to use, so that you can swap out implementations, but keep your middleware working.
• As a method of last resort, allow configuring your oauth middleware to specify the key to use. I say this is last resort, as attribute injection should happen primarily for routing and for specialized middleware with very specific domains; overwriting should be an exceptional condition.

[basz]

I found this pattern which sort of 'namespaces' attributes...