| Author |
Message
|
| javagals |
 Posted: Thu Jan 08, 2009 4:34 am Post subject: VB/.NET client not able to set MQEnvironment.userID & pw |
 |
|
Apprentice
Joined: 13 Aug 2008
Posts: 34
|
My VB/.NET client is sending os user id even after explicitly setting MQEnvironment.userId and MQEnvironment.password value.
Any idea why?
OS -> Windows XP
amqmdnet.dll version 1.0.0.3 (size 356)
MQServer version 6.0.1.0 running on Linux x86_64
_________________
Sridhar Javagal
Solution design and delivery |
|
| Back to top |
|
 |
| Vitor |
| Posted: Thu Jan 08, 2009 4:44 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
Can we assume that the connection issue you describe here has been resolved then? What action did you take? Are you still using a managed connection within .NET?
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| javagals |
| Posted: Thu Jan 08, 2009 4:50 am Post subject: |
|
|
Apprentice
Joined: 13 Aug 2008
Posts: 34
|
This is a part of the connection issue. MQ Server has a security exit which authenticates incoming connections using supplied user id and password. In this case, user id at MQ server end is the windows user id but, we are setting MQEnvironment.userId and MQEnvironment.password value in the client code. Somehow this is getting over written.
Any idea what's happening?
_________________
Sridhar Javagal
Solution design and delivery |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jan 08, 2009 4:59 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| javagals wrote: |
| Any idea what's happening? |
If you're using a managed connection (which you've not answered me about) then IIRC it doesn't use the MQEnvironment.userid & .password fields, but the signed on user.
I could be remembering wrong of couse.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| javagals |
| Posted: Thu Jan 08, 2009 5:39 am Post subject: |
|
|
Apprentice
Joined: 13 Aug 2008
Posts: 34
|
We are using amqmdnet.dll and VB/.NET client. Does it mean we are using managed connection? I know for sure we are not using the installed MQ client.
If we cant use MQEnvironment.userId then, how do we pass user id and password?
_________________
Sridhar Javagal
Solution design and delivery |
|
| Back to top |
|
|
| Vitor |
| Posted: Thu Jan 08, 2009 6:00 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| javagals wrote: |
| how do we pass user id and password? |
You don't. Use a different security solution.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| javagals |
| Posted: Fri Jan 09, 2009 5:14 am Post subject: |
|
|
Apprentice
Joined: 13 Aug 2008
Posts: 34
|
We are providing a service and business requirement is to authenticate incoming connections via userid/pwd. This has been implemented in MQ Client/Server channel using security exit. Many clients using Java can connect to us successfully but clients with VB/.NET have this 2059 issue. Is there any way to force the .net dll to use mq environment variable and get it to work?
_________________
Sridhar Javagal
Solution design and delivery |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jan 09, 2009 5:20 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
|
| Back to top |
|
|
| javagals |
| Posted: Fri Jan 09, 2009 5:54 am Post subject: |
|
|
Apprentice
Joined: 13 Aug 2008
Posts: 34
|
This documentation is for mq version 7.
I am using MQ Server version 6.0.1.0 on Linux X86_64 platform. I have created security exit and deployed on MQ server.
Client written in VB/.NET using amqmdnet.dll fails to connect and throws 2059 error and I see a segmentation fault at MQ server security exit.
Client written in java which use some mq jar files work ok.
Do I need to write a different security exit at MQ server end to handle .net connections? or Do I have to write a pair of security exits at client/server end to handle .net connection.
Please kindly explain. Your help is much appreciated.
Regards,
_________________
Sridhar Javagal
Solution design and delivery |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jan 09, 2009 6:00 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| javagals wrote: |
| This documentation is for mq version 7. |
You'll find similiarly helpful documentation for v6.
You might start here which says:
| Quote: |
| Channel exits written for a non-managed client will not work. You must write new exits specifically for the managed client |
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| javagals |
| Posted: Fri Jan 09, 2009 6:29 am Post subject: |
|
|
Apprentice
Joined: 13 Aug 2008
Posts: 34
|
Java clients dont use the MQ client installation. They use mq jar files. So, they are managed connections. I have a security exit for managed connections and works for java not for VB/.NET
Please let me know if my understanding is not correct.
I have noticed that VB/.NET client does not accept MQEnvironment.userId and MQEnvironment.password fields it some how gets the local os id and forwards it for authentication.
Please let me know if you have any info on this.
_________________
Sridhar Javagal
Solution design and delivery |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jan 09, 2009 6:38 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| javagals wrote: |
Java clients dont use the MQ client installation. They use mq jar files. So, they are managed connections. I have a security exit for managed connections and works for java not for VB/.NET
Please let me know if my understanding is not correct. |
It's not correct. The Java functions use client connection "under the covers". A managed connection in this context is a connection type specific to .NET.
The documentation does explain this.
| javagals wrote: |
I have noticed that VB/.NET client does not accept MQEnvironment.userId and MQEnvironment.password fields it some how gets the local os id and forwards it for authentication.
Please let me know if you have any info on this. |
It's not "some how", it's "how it works". Again the documentation goes into this.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| javagals |
| Posted: Fri Jan 09, 2009 7:08 am Post subject: |
|
|
Apprentice
Joined: 13 Aug 2008
Posts: 34
|
Apologies if I am asking the same queuestion.
In short, do I need to write a new security exit at server end and a new security exit at VB/.NET client end to get this authentication bit working?
_________________
Sridhar Javagal
Solution design and delivery |
|
| Back to top |
|
|
| Vitor |
| Posted: Fri Jan 09, 2009 7:13 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| javagals wrote: |
| Apologies if I am asking the same queuestion. |
You do seem to be having a spot of bother believing this. 
| javagals wrote: |
| do I need to write a new security exit at server end and a new security exit at VB/.NET client end to get this authentication bit working? |
I think the part of the documentation which says:
| Quote: |
| You must write new exits specifically for the managed client |
that I posted further up this thread was pretty clear.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Jan 09, 2009 7:47 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You shouldn't need to write a new security exit at the server.
You should just need to write a new security exit at the client.
Or switch to using a regular client connection (and full MQ client install) instead of a managed client connection. |
|
| Back to top |
|
|
|
|
