Sijie Guo created BOOKKEEPER-631:
------------------------------------
Summary: Middleware 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
