I don't have an example for the second one yet, but the first one is simple.
You don't want clients to be able to set that header or property because
then clients could spoof another client. It is set by the broker based on
the authentication of the sender. If you're using username/password
authentication and you turn that feature on in the broker, then you should
be able to see that header in sent messages. You probably need to use the
latest version built from source code because of issue AMQ-940. (Or wait for
a 4.1 RC build to be released)
-Kelly
On 10/11/06, Pico Florin <[EMAIL PROTECTED]> wrote:
Hi!
Thank you Kelly for your quick response!
I would like to ask you if there is any example with the 2 solutions
that you gave me.
In the documentation recommended in the solution 1, it is said that:
" Once enabled this feature adds the JMS property JMSXUserID to each JMS
message so that a consumer can know exactly who the sender was using the
broker's authentication policy."
I was trying to do something like this (on the client
side): ((ObjectMessage)message).setJMSXUserIDProperty() but I didn't found.
Then I was thinking to ((ObjectMessage)message).setObjectProperty()
but what string property should I use to set up this JMSXUserID?
For the socond solution, I have no idea how to implement this. I
have no knowlege regarding the SSL connection, maybe a good example for
both server and client will reveal me how it realy works.
Thank you,
Florin
Kelly Campbell <[EMAIL PROTECTED]> wrote: Hi Pico,
There is a feature where ActiveMQ can set the JMSXUserId header to the
userid of the sender of the message. You can use that on the server side
to
determine what client is requesting it. The only issue with this is that
the
server has to trust the broker. Does that work for what you need?
Documentation is here: http://activemq.org/site/jmsxuserid.html
There's also now the option to authenticate and secure a connection using
client SSL certificates in the 4.1 codebase. I'm working on some changes
in
my spare time to allow increased flexibility of this so you can do things
like have the JMS client check the broker's certificate as well to ensure
it
is as expected.
-Kelly
On 10/10/06, Pico Florin
wrote:
>
> Hi!
> I have a P2P architecture where many clients send messages to JMS
> server installed on a web server (Resin). The messages that the client
send
> to be persisted in DB installed on on the server side. Before that
> operation the client should be authenticated against this database
> installed on the server side. The client should send its credentials in
> order to be authorized.
> Now the problem:
> I have seen that in the JMS API exists a method:
> ConnectionFactory.createConnection(String userName, String password)
> but I think that these credentials are for the service installed on
> the server in order to be connected to it, but I am afraid I cannot use
> the client's credentials for the application.(E.g. user1/pw1 authorized
> to be connected to the JMS server and use the service,
> user2/pw2 authorized to be connected to the JMS server and use the
service,
> etc). These credentials are also on the DB server installed on the
> server. The question is: am I wrong with this opinion or not? If yes,
> what should I write in the server side in order to accept many clients
to
> be connected?
> Another solution is to set up a object property in header of the
> message, where I put my credentials encrypted. But is that ok(is this a
> real solution)?
> Any ideas and suggestions are appreciated.
> Florin
>
>
>
>
> ---------------------------------
> Yahoo! Photos – NEW, now offering a quality print service from just 8p a
> photo.
>
---------------------------------
All new Yahoo! Mail "The new Interface is stunning in its simplicity and
ease of use." - PC Magazine
