Differences

This shows you the differences between two versions of the page.

Link to this comparison view

irc:1489705200 [2017/05/27 13:44] (current)
Line 1: Line 1:
 +[05:15:42] <​aotbot>​ Is it possible to use Immutables (https://​immutables.github.io/​) as DataObjects for ServiceProxy definitions?​
 +
 +[17:39:53] <​RebelGeek>​ Hello, I was able to get OAuth2 working in CloudFoundry. The only thing that I need now is for the OAuth2 handler to also make a call to /userinfo to get the user's information PRIOR to hitting the RedirectHandler which will authenticate via authorities. What is the suggested way of doing that?
 +
 +[23:22:34] <​xkr47>​ temporalfox,​ got SNI to work
 +
 +[23:25:30] <​xkr47>​ temporalfox,​ also managed to automatically extract all aliases from a PEM certificate (Subject CN + SubjectAltNames) so I can automatically register all of them to the keystore
 +
 +[23:28:55] <​temporalfox>​ good xkr47
 +
 +[23:29:16] <​xkr47>​ should work with dynamic reconfiguration too
 +
 +[23:29:27] <​xkr47>​ so now I'm thinking how to expose that..
 +
 +[23:29:32] <​temporalfox>​ you mean with a KeyManagerFactory ?
 +
 +[23:29:34] <​xkr47>​ through the event bus perhaps?
 +
 +[23:29:47] <​xkr47>​ yeah
 +
 +[23:30:16] <​xkr47>​ I use the code I pasted ~a week ago for KeyManagerFactory
 +
 +[23:30:21] <​temporalfox>​ I don't know it's your use cases :-)
 +
 +[23:30:46] * xkr47 reads up on creating microservices with vertx
 +
 +[23:32:24] <​xkr47>​ so not eventbus but ServiceDiscovery
 +
 +[23:32:40] <​temporalfox>​ so you are doing some kind of proxy ?
 +
 +[23:32:55] <​temporalfox>​ smart proxy in front of dynamic services exposed thrhough the proxy ?
 +
 +[23:33:03] <​xkr47>​ yes: https://​github.com/​NitorCreations/​nitor-backend/​
 +
 +[23:33:06] <​temporalfox>​ cool
 +
 +[23:33:12] <​temporalfox>​ you might be interested in that
 +
 +[23:33:19] <​xkr47>​ it does all the http2, auth etc
 +
 +[23:33:22] <​temporalfox>​ https://​github.com/​vietj/​vertx-http-proxy
 +
 +[23:33:39] <​temporalfox>​ I'm trying to get in this component, the logic for proxying http
 +
 +[23:33:51] <​xkr47>​ oh I'm all done with that already
 +
 +[23:34:05] <​xkr47>​ supports websockets too and http2 on the server side, http1.1 client
 +
 +[23:34:05] <​temporalfox>​ well actually my goal is to implement a correct proxy
 +
 +[23:34:11] <​xkr47>​ me too
 +
 +[23:34:20] <​temporalfox>​ and handle things like error handling
 +
 +[23:34:21] <​xkr47>​ it's my fourth http proxy since 2001
 +
 +[23:34:31] <​xkr47>​ yup.. all that covered
 +
 +[23:34:43] <​xkr47>​ I did find some pipelining bugs in vertx I haven'​t reported yet
 +
 +[23:34:51] <​temporalfox>​ I'm actually working on passing a TCP for the proxy
 +
 +[23:34:58] <​temporalfox>​ TCK
 +
 +[23:35:03] <​xkr47>​ ?
 +
 +[23:35:39] <​temporalfox>​ http://​coad.measurement-factory.com
 +
 +[23:35:41] <​xkr47>​ here's the proxy impl https://​github.com/​NitorCreations/​nitor-backend/​blob/​master/​src/​main/​java/​io/​nitor/​api/​backend/​proxy/​Proxy.java
 +
 +[23:35:54] <​temporalfox>​ it's a TCK that test correctness of forward / reverse proxy
 +
 +[23:36:01] <​xkr47>​ :)
 +
 +[23:36:03] <​xkr47>​ good, thanks
 +
 +[23:36:08] <​temporalfox>​ and with vertx-http-proxy I'm trying to get all the tests passing
 +
 +[23:37:03] <​temporalfox>​ also the proxy does not depend on vertx web on purpose
 +
 +[23:37:15] <​temporalfox>​ it just aims to proxy requests with rewriting
 +
 +[23:37:19] <​xkr47>​ yeah I understand
 +
 +[23:37:20] <​temporalfox>​ so a small components that can be reused
 +
 +[23:37:26] <​temporalfox>​ to implement things like you do
 +
 +[23:38:17] <​xkr47>​ the use of RoutingContext is quite minimal
 +
 +[23:38:27] <​temporalfox>​ I recognize indeed that if you proxy a chunked request with http 1.0 you need to buffer the full response
 +
 +[23:38:29] <​xkr47>​ I could extract that to an interface
 +
 +[23:38:52] <​xkr47>​ what do you mean ?
 +
 +[23:39:03] <​xkr47>​ chunked requests don't exist in http/1.0
 +
 +[23:39:05] <​temporalfox>​ yes
 +
 +[23:39:15] <​temporalfox>​ so if you proxy a backend chunked response
 +
 +[23:39:19] <​temporalfox>​ and talk to an http 1.0 client
 +
 +[23:39:25] <​temporalfox>​ it implies to buffer the full response
 +
 +[23:39:27] <​temporalfox>​ on the proxy
 +
 +[23:39:33] <​xkr47>​ ah chunked response, not request :)
 +
 +[23:39:49] <​temporalfox>​ sorry :-)
 +
 +[23:39:49] <​temporalfox>​ it's late
 +
 +[23:39:51] <​xkr47>​ yes.. I have left out HTTP/1.0 support in my proxy
 +
 +[23:40:15] <​xkr47>​ I have been implementing HTTP/1.0 support too many times already :)
 +
 +[23:40:34] <​xkr47>​ last time I wrote the whole stack myself using java.nio
 +
 +[23:41:58] <​xkr47>​ I have filed some 2-3 vertx bugs/PR:s already just to implement the proxy :)
 +
 +[23:42:20] <​temporalfox>​ ok
 +
 +[23:42:29] <​temporalfox>​ the vertx-http-proxy also allowed me to find some limits
 +
 +[23:42:33] <​temporalfox>​ and fix bugs in vertx core
 +
 +[23:42:39] <​temporalfox>​ maybe I hsould find a list
 +
 +[23:42:41] <​temporalfox>​ for you
 +
 +[23:42:52] <​xkr47>​ heh
 +
 +[23:43:05] <​temporalfox>​ like some incorrect netty requests failure were not handled by vertx exception handler
 +
 +[23:43:35] <​temporalfox>​ https://​github.com/​eclipse/​vert.x/​issues/​1862
 +
 +[23:43:46] <​xkr47>​ I hope to finish the client pipeline PR soon so we can get it fixed.. was quite nasty
 +
 +[23:44:16] <​xkr47>​ also I'm not sure if it's the best way to do it, but I at least have tests almost ready to reproduce
 +
 +[23:44:23] <​temporalfox>​ HttpClient leaves connection open on websocket request failure (resource leak)
 +
 +[23:44:25] <​temporalfox>​ that was you
 +
 +[23:44:36] <​temporalfox>​ if you provide at least a reproducer
 +
 +[23:44:37] <​temporalfox>​ it's cool
 +
 +[23:44:54] <​temporalfox>​ this one too
 +
 +[23:44:55] <​temporalfox>​ https://​github.com/​eclipse/​vert.x/​issues/​1727
 +
 +[23:44:58] <​temporalfox>​ "Too long max headers results in empty reply instead of 400 response"​
 +
 +[23:45:11] <​temporalfox>​ https://​github.com/​eclipse/​vert.x/​issues/​1724
 +
 +[23:45:15] <​temporalfox>​ Allow to configure maxInitialLineLength and maxHeaderSize in the HttpClient
 +
 +[23:45:37] <​xkr47>​ nice
 +
 +[23:46:38] <​temporalfox>​ anyway if you feel to contribute to vertx-http-proxy to factor this proxy logic in a single place it would be great :-)
 +
 +[23:46:49] <​temporalfox>​ so this could become a small vertx component
 +
 +[23:46:57] <​temporalfox>​ that helps people implementing case like you
 +
 +[23:47:09] <​temporalfox>​ for building api management / api gateway / smart proxies
 +
 +[23:47:21] <​xkr47>​ yeah it would be good
 +
 +[23:47:36] <​xkr47>​ so I just paste my implementation over, right? :D :D :D
 +
 +[23:47:49] <​temporalfox>​ if it passes the full coad TCK, why not
 +
 +[23:47:49] <​temporalfox>​ :-)
 +
 +[23:48:07] <​xkr47>​ want to finish this SNI stuff first
 +
 +[23:48:25] <​xkr47>​ so I can then finish letsencrypt with the tls-sni challenge
 +
 +[23:48:36] <​temporalfox>​ ah yes
 +
 +[23:49:13] <​xkr47>​ I see that microservices is a separate bundle
 +
 +[23:49:33] <​xkr47>​ so I'm wondering whether it would be better to use the event bus as an interface to the dynamic keystore configuration
 +
 +[23:50:13] <​xkr47>​ like vertx.eventBus().publish("​keystore.add",​ new Object[] { certChain, privateKey });
 +
 +[23:51:12] <​temporalfox>​ why don't you use rather vertx clsutered data ?
 +
 +[23:51:31] <​temporalfox>​ if it needs a certificate and does not find it locally, it can lookup in shared data
 +
 +[23:51:37] <​temporalfox>​ and cache the result locally for a while
 +
 +[23:51:50] <​xkr47>​ I don't know that yet
 +
 +[23:52:24] <​xkr47>​ what kind of setup were you envisioning?​
 +
 +[23:52:52] <​xkr47>​ keep certs on one node only and share over cluster?
 +
 +[23:53:17] <​temporalfox>​ I don't know about your global architecture actually
 +
 +[23:53:35] <​temporalfox>​ iut seems that you are trying to get metadata from dynamic service
 +
 +[23:53:38] <​xkr47>​ yeah.. our proxy is pretty stateless
 +
 +[23:53:40] <​temporalfox>​ like a store
 +
 +[23:54:49] <​xkr47>​ I'll do a quick hack with event bus first to see if the whole shebang works
 +
 +[23:54:51] <​xkr47>​ ^^
 +
 +[23:55:11] <​temporalfox>​ ok
 +
 +[23:55:19] <​temporalfox>​ are you doing this for fun ?
 +
 +[23:55:45] <​xkr47>​ vertx is always fun, wdym? :)
 +
 +[23:56:11] <​temporalfox>​ I mean are you implementing a business case ?
 +
 +[23:56:11] <​xkr47>​ the letsencrypt stuff is both for my home server and for our company servers
 +
 +[23:56:16] <​temporalfox>​ ok
 +
 +[23:56:24] <​xkr47>​ the tls-sni thing is not strictly necessary
 +
 +[23:56:38] <​xkr47>​ so I'm trying that out for fun
 +
 +[23:56:46] <​xkr47>​ I could easily just implement the http-01 challenge instead
 +
 +[23:57:03] <​temporalfox>​ yes it seems enough :-)
 +
 +[23:57:08] <​temporalfox>​ and less convoluted
 +
 +[23:57:59] <​xkr47>​ well.. our port 80 service is currently redirecting everything to https and runs in a separate proces (because of systemd which can only pass a single serversocket to a java instance)
 +
 +[23:58:18] <​xkr47>​ so we have two systemd services, one for 80 and one for 443
 +
 +[23:58:33] <​xkr47>​ so it would be more .. demanding .. to coordinate the certificate challenge between two jvms
 +
 +[23:58:51] <​xkr47>​ so I though implementing the tls-sni would let me handle it all directly in-jvm
 +
 +[23:59:15] <​temporalfox>​ ok
 +
 +[23:59:40] <​xkr47>​ I'm not a big systemd fan, but that's what we use on the company servers