Approvals: 0/1
[08:26:03] <temporalfox> purplefox hi
[09:59:40] <purplefox> morning tekacs
[09:59:43] <purplefox> temporalfox:
[10:00:30] <purplefox> tekacs: damn autocomplete (meant to get temporalfox ), but morning to you anyway !
[10:10:55] <temporalfox> purplefox I made a (small) PR for a bugfix I fixed in vertx-core, would you mind to validate it as this is a bit in a touchy part ?
[10:11:21] <purplefox> ok
[10:13:29] <purplefox> temporalfox: could you explain the PR a bit?
[10:14:11] <temporalfox> when using an HttpServer in a worker context, the handshake put the connection in the worker thread
[10:14:22] <temporalfox> along with the handler callback
[10:14:37] <temporalfox> when other channel event arrive, they find null
[10:14:42] <temporalfox> and just don't do anything
[10:15:01] <temporalfox> for instance setting an HttpServerRequest#endHandler with a worker thread never gets the endHandler called
[10:15:41] <temporalfox> because the VertxHandler#channelRead gets null from the connectionMap
[10:15:53] <temporalfox> when it gets the LastHttpContent event
[10:16:48] <purplefox> yep that makes sense, thanks
[10:17:26] <purplefox> the other PR - I am still not sure about a few things (the metrics context one)
[10:19:12] <temporalfox> I'm still working on this PR
[10:19:23] <temporalfox> writing test for workers
[10:19:33] <temporalfox> so perhaps we can review it later
[10:19:47] <temporalfox> I realized a few wrong things again
[10:20:37] <temporalfox> handling and clarify the metrics behavior with the same server is started in several contexts (scalling)
[10:20:49] <temporalfox> I'm not even sure it's handled correctly
[10:30:16] <purplefox> temporalfox: with the PR I just merged - can you make sure the same issue isn't present with NetServer/NetClient/HttpClient too?
[10:30:34] <temporalfox> purplefox sure no problem
[11:08:49] <purplefox> pmlopes: Morning Paulo :)
[11:09:15] <pmlopes> good morning
[11:09:41] <purplefox> pmlopes: how are you?
[11:10:08] <pmlopes> i pushed a few minutes ago the JWT code for vertx-auth, it is now on par with auth0 (the reference impl for NodeJS) jwt implementation
[11:10:32] <pmlopes> purplefox: i am fine, and you?
[11:10:54] <temporalfox> hi pmlopes have you started yet ?
[11:10:54] <purplefox> great. I am pretty much well, although it's a horrible day today raining
[11:11:16] <pmlopes> purlplefox: i am now looking to apex and started to create the jwt handler.
[11:11:33] <pmlopes> temporalfox: no, not officially
[11:11:54] <purplefox> pmlopes: i have just pushed some changes to my auth_refactor branch for the latest changes - i was wondering could you take a look and provide some feedback?
[11:16:14] <purplefox> all tests are passing now, but it needs docs still. I want to make sure the Api looks ok so we are future proofeed for other auth methods
[11:16:15] <pmlopes> i did merge them to my fork and i still have some compilation issues about the ClusterSerializable implementation on CacheableUser and ShiroUser
[11:16:34] <purplefox> right, you also need to build vertx-core from the “bits and pieces” branchg
[11:17:17] <purplefox> as i made some changes to the clusterserializable api
[11:17:21] <purplefox> (and a few other things)
[11:35:37] <purplefox> pmlopes: do you think “User” is a good name for the new interface in auth?
[11:41:07] <pmlopes> purplefox: humm that is a tricky, for example in java.security a “Principal” can be a user, in JWT and SAML a “Subject” is a user, in OAuth “User” is a user…, i think a user as a human but i think principal very java-ish and subject kind of too abstract… so i'm ok with user… but maybe theres a better naming…
[11:43:03] <purplefox> yeah security terms can be tricky
[11:44:28] <purplefox> i often get confused between “subject” and “principal”
[12:30:44] <purplefox> pmlopes: if a user is using JWT for auth, then what would be the principal?
[12:41:48] <pmlopes> purplefox: at the moment i am returning the json payload as the principal, since the property “sub” is according to the spec optional
[12:43:31] <pmlopes> for example on the tests i wrote this would be a principal/user: {“sub”:“Paulo”,“iat”:1431695313,“exp”:1747055313,“roles”:[“admin”,“developer”,“user”],“permissions”:[“read”,“write”,“execute”]}
[12:58:39] <purplefox> temporalfox: i am getting this error during codegen: Could not generate model for io.vertx.ext.auth.shiro.ShiroAuth: A concrete interface cannot extend more than two concrete interfaces
[12:58:55] <purplefox> temporalfox: i assume it really means “more than ONE concrete interface” ?
[13:36:00] <temporalfox> purplefox yes more than one indeed
[13:40:34] <purplefox> pmlopes: ok cool
[17:17:41] <aesteve> hi everyone !
[17:19:39] <aesteve> purplefox: if you have a minute I'd need a last advice regarding an example let me know when you're available :)
[17:33:23] <purplefox> aesteve: sure, please go ahead :)
[17:36:33] <aesteve> I'm almost done with the example, the only part that remains is the “live update” through websocket
[17:37:40] <aesteve> quick reminder : it's an RSS agregator, a verticle reads RSS feeds periodically and inserts new feed entries into redis
[17:38:19] <aesteve> when you ask (through a REST api) for the feed entries : it lists the entries in redis and sends them to the client, nothing fancy
[17:39:35] <aesteve> but for real-time updates I need to keep a list of subscribers somehow, somewhere
[17:40:14] <aesteve> like “these 3 users are currently connected through websocket, browsing their feeds, if you fetch any update in their subscribptions, notify them”
[17:41:38] <aesteve> hence I need some dialog between the web verticle (handling websockets) and what I called the broker verticle
[17:42:20] <aesteve> and I don't know if eventBus communication should be the way to go ?
[17:42:53] <purplefox> i'm not sure i understand what you mean by “if you fetch any update in their subscribptions, notify them”
[17:43:32] <aesteve> you read their RSS subscriptions (like bbc.co.uk, cnn.com, …) and find some new entries the clients don't know about
[17:43:56] <aesteve> and you know they're on the “news page” 'cause a websocket is opened
[17:44:06] <purplefox> so why don't you get them to subscribe to an address “new feeds”
[17:44:16] <purplefox> and when a new feed arrives you can post to that address
[17:44:29] <aesteve> and then have the javascript directly read the event bus ?
[17:44:43] <purplefox> sure, that's what it's for :)
[17:44:54] <purplefox> have you seen the event bus bridge stuff?
[17:44:58] <aesteve> but I'm wondering about authentication
[17:45:17] <aesteve> like, how do I know which user it is (and which feeds he subscribed to)
[17:45:35] <purplefox> why do you care?
[17:46:11] <aesteve> because I won't push to someone news from lemonde.fr if he only has subscribed to bbc.co.uk ?
[17:46:20] <purplefox> actually… can you do me a favour? I am totally snowed under right now.. could you post this as a thread on the google group then people can look at it asyncrhonously
[17:46:34] <aesteve> ok np :)
[18:07:58] <tony_> loving vertx [18:08:15] <tony_> looking for a way to know what modules and veticles are running
[18:08:43] <tony_> would be really nice to have something like docker ps from command line [18:17:45] <tony_> anyone there - how do I keep track of nodes in cluster and verticles running on cluster
[18:30:57] <temporalfox> tony_ probably the next version of the CLI for 3.0 will do that [18:31:07] <temporalfox> tony_ for 2.x looks at mod-shell it more or less does that
[18:32:27] <tony_> I have the mod shell running (https://github.com/crashub/mod-shell) [18:32:40] <temporalfox> tony_ you can do your own command if you want
[18:32:57] <temporalfox> tony_ that runs some code on the cluster and get replies [18:33:04] <temporalfox> tony_ and then display it
[18:33:59] <tony_> when I run vertx deployments - it only ever shows itself in the list (id org.crashub~vertx.shell~2.1.0)
[18:34:15] <temporalfox> tony_ maybe it's bugged
[19:02:56] <purplefox> hi AlexLehm
[19:03:00] <purplefox> AlexLehm: how is the mail stuff going?
[19:04:32] <AlexLehm> hi, i can write you a status later (after dinner)
[19:05:11] <AlexLehm> ~30mins or so
[19:17:31] <purplefox> AlexLehm: sure, can you post it on the dev group? thanks
[19:50:09] <AlexLehm> ok will do
[21:25:06] <AlexLehm> purplefox, ok, i sent a mail with the status to the list
[21:36:07] <jtruelove> purplefox: are there any examples of setting the peer cerficate on a websocket client? I'm setting the setPemKeyCertOptions on the client builder and giving it a client key and cert which gets accepted but the server blows up when it tries to grab chain off the request
[22:01:52] <jtruelove> do you have to have every client cert setup on the server
[22:02:25] <jtruelove> is that what causes something like javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
[22:14:33] <D-Spair> Is there some documentation for Vert.x 3.0.0 and io.vertx.core.logging.Logger??
[22:15:31] <AlexLehm> the docs for the current wip version are on vert-x3.github.io
[22:16:01] <AlexLehm> jtruelove, you should only need to set up the ca correctly, you do not have to set up the actual client cert on the server (I would expect)
[22:16:10] <D-Spair> AlexLehm: Yeah, and I cannot find anything but the JavaDocs for that.
[22:16:27] <AlexLehm> i think there is nothing except javadoc for the classes yet
[22:16:40] <AlexLehm> should be almost the same as in vertx 2 though
[22:17:04] <AlexLehm> the log classes more or less wrap JUL with a delegate for the other loggers
[22:17:57] <D-Spair> AlexLehm: Thanks for the confirmation…
[22:23:13] <jtruelove> cool AlexLehm: i'll post a sample of what I'm doing on the client and server
[22:24:00] <jtruelove> see if i'm doing something stupid, i'm no expert on the security stuff. I'm able to make the connection with my client cert but on the server when I go to grab at the cert chain it just blows up
[22:24:32] <jtruelove> so maybe while my cert is correct enough to be set on the client maybe it isn't actually correct
[22:39:47] <AlexLehm> i think you have to provide a jks with your ca, then the certs should be valid
[22:42:46] <D-Spair> Here's an example of what I am doing to configure SSL for Vert.x 3.x: https://gist.github.com/InfoSec812/a45eb3b7ba9d4b2a9b94
[22:43:51] <D-Spair> In that gist, there is logic to use an existing PEM/PKCS12/JKS keystore or automatically generated a self-signed cert.
[22:45:16] <jtruelove> that's all server side though? i have that part working it's the generating a client cert in my test app that seems like it isn't functioning correctly
[22:45:58] <D-Spair> jtruelove: Oh, sorry… I should have read the backlog… ;)
[22:46:45] <jtruelove> yeah i've got my server handling that and i can hit it via wss in the browser once i added its cert to my browser which was a pain in the ass
[22:47:36] <D-Spair> jtruelove: Yeah. Client-side certs without a valid CA is definitely complicated. The server would have to “trust” every client cert generated unless you implement your own CA or use someone elses.
[22:47:46] <jtruelove> my issue is on the client when the request makes it to the server and i call peerCertificateChain stuff blows up
[22:48:20] <D-Spair> jtruelove: Definitely understand… How are you presenting the client cert? Is the client cert generated from a CA cert?
[22:48:33] <D-Spair> s/generated/signed by/
[22:48:38] <jtruelove> lemme grab you a gist 1 second
[22:48:42] <jtruelove> it's a tad complex
[22:48:54] <D-Spair> jtruelove: I have a feeling that is an understatement.
[22:48:58] <jtruelove> and based on what i could piece together from reading about bouncycastle
[22:52:49] <jtruelove> https://gist.github.com/jtruelove/c4bac7bcbc8e960bc721
[22:52:56] <jtruelove> here's a client sample
[22:53:27] <jtruelove> then on the sever i just have a listener on /connect that gets the http request and tries to call peerCertificateChain
[22:53:57] <jtruelove> if that succeeded i'd look at it then call upgrade on the httprequest etc..
[22:54:17] <jtruelove> one thing i'm going to try real quick is generating the cert via the command line and seeing if that works
[22:55:05] <jtruelove> the reason i want to generate the certs in code is i want to create a load testing client that can simulate traffic and being using ssl
[23:01:01] <D-Spair> jtruelove: Yep, unless you add every client cert generated to the server's keystore, it will not be able to be validated by the server.
[23:01:44] <jtruelove> and you won't be able to get the peer cert chain etc..
[23:02:04] <jtruelove> as there is no 'trustAll' option on the server
[23:02:15] <D-Spair> The other option is having some sort of server-side application which participates with generating the client cert. Generate the cert on the client side as a CSR and send it to the server for signing and addition to the trusted keystore.
[23:02:31] <AlexLehm> i think you only need to sign the client cert with your ca
[23:02:36] <jtruelove> because having a cert that you can't verify doesn't add a ton of value
[23:02:53] <AlexLehm> haven't used client certs in a while though
[23:03:12] <D-Spair> AlexLehm: Agreed, but he would need to create a CA cert and have that CA cert in the trusted keystore.
[23:03:21] <AlexLehm> yes
[23:03:34] <AlexLehm> but the trusted store can be specific to the server/client
[23:03:42] <D-Spair> And all clients would have to sign their certs using that CA cert, which is a whole other can of security worms..
[23:04:15] <jtruelove> if you are looking at having tons of clients this isn't going to scale real easily
[23:04:21] <D-Spair> Woot! I'm now able to connect to my ZNC IRC bouncer from my tablet! Mobile IRC FTW!
[23:05:30] <D-Spair> Mobile IRC is sweet!