[
https://issues.apache.org/jira/browse/BOOKKEEPER-631?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13697507#comment-13697507
]
Sijie Guo edited comment on BOOKKEEPER-631 at 7/2/13 5:07 AM:
--------------------------------------------------------------
[~ikelly] as I mentioned in the description, "this interface is quite similar
as netty handlers. I was considering how to consolidate them".
but so far, I think the benefits to having a separate interface: 1) we could
put sending respond in a central place without spreading writing channel.write
crossing possible all handlers 2) we could guarantee a bad implementation would
not drop requests (an netty handle would drop the request if it doesn't pass
its unhandled messages to downstream) and it is easier for debugging and
troubleshooting.
was (Author: hustlmsp):
[~ikelly] as I mentioned in the description, "this interface is quite
similar as netty handlers. I was considering how to consolidate them".
but so far, I think the benefits to having a separate interface: 1) we could
put sending respond in a central place without spreading writing channel.write
crossing possible all handlers 2) we could guarantee a bad implementation of
netty handler dropping requests (if it doesn't pass its unhandled messages to
downstream) and it is easier for debugging and troubleshooting.
> RequestProcessor Proposal
> -------------------------
>
> Key: BOOKKEEPER-631
> URL: https://issues.apache.org/jira/browse/BOOKKEEPER-631
> Project: Bookkeeper
> Issue Type: New Feature
> Components: bookkeeper-client, bookkeeper-server
> Reporter: Sijie Guo
>
> This JIRA tries to propose a *Middleware* concept, which is a kind of
> request/response handler to intercept bookie request/response flow for
> different purposes.
> Different *middleware*s serve different purpose:
> - *StatsMiddleware* is to collect stats of requests
> - *AuthMiddleware* is to authenticate requests
> - *ACLMiddleware* is to serve authorization.
> - any customized middleware could be added to serve their request
> intercepting.
> the middlewares are loaded from configuration to process request/response in
> order.
> request -> (middleware 1) -> (middleware 2) -> (middleware N) -> response
> each middleware could decide: whether it could process the request or not? if
> it can't process, it passes the request to its downstream middleware. if it
> could, processes the request and decide whether to pass the request to
> downstream or not.
> for example, an auth bookie could load two middlewares:
> request -> AuthMiddleware -> BookieMiddleware -> response
> The *AuthMiddleware* could intercept *authenticate* requests or requests with
> *authenticate* information (such as Token). if the request is authenticated,
> pass it to BookieMiddleware to process the requests; otherwise, it stopped
> and respond with EUA response.
> A non-auth bookie could just load BookieMiddleware without any authentication.
> prototype of this idea in github. the interface in the prototype is not
> finalized, since the middleware concept is quite similar as netty channel
> handler. I am thinking how to consolidate them.
> https://github.com/sijie/bookkeeper/commit/d23df97b209170852f2ce6676a49c97e72ecb2ee
> a token-based authentication middleware example:
> https://github.com/sijie/bookkeeper/tree/middlewares/bookkeeper-server/src/main/java/org/apache/bookkeeper/security/token
> or if you want to make authentication flow like this:
> - client instantiates a connection
> - client sends credential first
> - after client verified the credential, all the following requests are
> authenticated.
> you could implement a middleware maintaining all incoming requests, if the
> first message is not credential, respond EUA and close the channel, if the
> first message is credential message and it is authenticated, mark this
> channel as authenticated and bypass all its following requests.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
