qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rajith Attapattu" <rajit...@gmail.com>
Subject Re: [ANN] java RC3 available
Date Thu, 06 Sep 2007 13:19:57 GMT
Is everybody happy?

Can we get the release rolling?

Regards,

Rajith

On 9/4/07, Martin Ritchie <ritchiem@apache.org> wrote:
>
> On 04/09/07, Robert Greig <robert.j.greig@gmail.com> wrote:
> > On 04/09/07, Martin Ritchie <ritchiem@apache.org> wrote:
> >
> > > The two files provide access to two different components they could be
> > > combined but that would then require a new file format. The
> > > jmxremote.access does not confer any permission to connect to the
> > > broker for sending messages only the level of management control that
> > > they have over the entire broker. The access file controls only
> > > connections for broker access, sending and receiving via a set
> > > virtualhost. You can think of it as access controls port 5672 and
> > > jmxremote.access controls 8999.
> >
> > I definitely think they should be combined. I think that
> > "authorisation" should be controlled in a single place to make it as
> > simple as possible for the user. It seems to me that we ended up with
> > two files for simplicity/speed of implementation rather than good
> > design.
>
> We haven't done a design :)
>
> > > They could be if you wrote a new PasswordFile class. I wrote the
> > > PlainPasswordVHostFile as a demonstration of how you could combine the
> > > PasswordFile and the AccessManager classes.
> >
> > So which approach are we recommending for users? I am trying to put
> > together clear documentation on this.
>
> The Base64MD5 PF is the only one I would recommend. For any sort of
> secure usage as that is the only one that encrypts(albeit weakly) the
> password.
>
> Access Management needs more work so if you really need it then the
> only option currently is to run n brokers with different configs
>
> > RG
> >
>
>
> --
> Martin Ritchie
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message