Differences

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

Link to this comparison view

irc:1431900000 [2017/05/27 13:44] (current)
Line 1: Line 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!