On 29 June 2016 at 19:38, Gordon Sim <[email protected]> wrote: > On 29/06/16 16:52, Robbie Gemmell wrote: >> >> I think I misinterpreted your use of "predefined" earlier. I was only >> really considering whether I think it makes sense for a client example >> to use user credentials by default (I do, but also like the >> flexibility of your patch, so will overlook that :P), I dont actually >> think the "guest" (or whatever that name it is easily changed to) user >> always needs to be pre-defined on the server from the get go. Other >> than perhaps implicitly by overlooking what you were actually saying, >> I don't think I've said it needs to be. > > > Indeed, I think we are in complete agreement on the client side. The change > I've made keeps the significant educational value of showing how the > username and password are specified, but allows them to be chosen by the > user. > >> Adding a user [of any name you >> choose] seems a valuable exercise to me, I've have no problem in >> requiring users do that themselves, and many servers ship in such >> fully locked down states for that reason (I used two yesterday). >> >> Regardless I'd say its as easy to overlook disabling anonymous as it >> is to overlook changing a user account used / added while at the basic >> stage of running an example, particularly if the things using it dont >> necessarily stop working once you do add authentication later. > > > (This is where we have a minor disagreement, which is not really relevant to > the main purpose of the thread. However... just for the enjoyment of the > debate... my view, which may be biased by the servers I'm more familiar > with, is that the enablement of anonymous is fairly obvious from reading the > appropriate config, whereas the existence of a dummy user is only apparent > if you query the userbase *and* are aware that the user was added on > install. Admittedly the name 'guest' is something of a clue. However e.g. > the 'authenticatePeer: no' in a router config is in my view a more visible > signal of the current status.) >
I've not been proposing folks must actually use "guest", or necessarily any other kind of testing-only name, its just something that worked for a few servers out the box and so seemed as good as any other arbitrary name to use. Certainly for other servers not having any out the box config, I'd think folks would be as inclined to pick something else they might not actually be entirely against sticking around later. Thats even assuming they have such real choice at all of course, and can actually see any of the server config, i.e the auth names and config of the thing they are connecting to arent assigned in some way by a separate administrator of a server they only happen to be using (despite how easy it may be to start a server locally). Hit that one many times :) As a bit of a tangent, I'm not actually the biggest fan of 'authenticatePeer: no' since it doesnt actually stop the router offering mechnisms that do authentication and then fail when used. The name kind of feels like its saying the equivalent of qpidd's --auth=no, but apparently isnt. >>> However, my focus at present is really just about the client side and >>> whether the examples could be made more flexible. That would make them >>> more >>> useful against different servers with different views on default >>> configurations. >>> >>> More complete patch for comments: https://reviews.apache.org/r/49380/ >>> >> >> Looks good to me (I was actually doing the same before I spotted your >> mail :P), feel free to push it in. > > > Done, thanks! > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
