[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!