| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| WMQ security exit, buffer data and EBCDIC vs ASCII |
« View previous topic :: View next topic » |
| Author |
Message
|
| zpat |
 Posted: Sat Jul 02, 2011 10:28 am Post subject: |
 |
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
It looped when they removed the server side exit (and forgot to tell me), it worked when they replaced it. Both client side and server side exits are working on other customer's channels and don't have bugs as such. Ours is now OK (no changes were made to the code).
July 13th? A fair chance that I will be there. |
|
| Back to top |
|
 |
| RogerLacroix |
| Posted: Tue Jul 05, 2011 6:46 am Post subject: |
|
|
Jedi Knight
Joined: 15 May 2001
Posts: 3264
Location: London, ON Canada
|
Hi,
Well, you made me do some regression testing of MQAUSX today. I was worried that maybe there was a bug in MQ but happily there is not. I do not think your code is designed properly if it loops.
MQAUSX uses both a client-side security exit and server-side security exit to exchange encrypted user credentials. To avoid "user issues" when they deploy MQAUSX, here is what I did:
- If the user deploys the client-side security exit on the wrong channel or forgets to deploy the server-side security exit then the client-side security exit does nothing and the channel functions as if the channel does not have MQAUSX deployed.
i.e.
MQXR_INIT
MQXR_INIT_SEC
MQXR_SEC_PARMS
MQXR_TERM
- I designed the server-side security exit to be extremely versatile.
1) It works with the client-side security exit to receive encrypted user credentials
2) It works without the client-side security exit to receive user credentials in plain text
3) It works as server-side security exit ONLY (NoAuth=Y) and does not receive user credentials. It filters UserID and/or IP address and/or SSL data
I just did regression testing with WMQ v7.0.1.4 and v7.0.1.5 of these scenarios and everything is working fine. You should take a look at your code and refine/redesign it (or fix it) so that it does not loop.
Food for thought.
Regards,
Roger Lacroix
Capitalware Inc.
_________________
Capitalware: Transforming tomorrow into today.
Connected to MQ!
Twitter |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Jul 05, 2011 7:24 am Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| It's not our code though. it was written by the third-party. I would like to improve it but unlikely to get the time to do so. |
|
| Back to top |
|
|
| skoobee |
| Posted: Tue Jul 05, 2011 9:32 pm Post subject: |
|
|
Acolyte
Joined: 26 Nov 2010
Posts: 52
|
There was a recent APAR IC74296:
[quote]
A WebSphere MQ v7 Requester-Server channel defined with a security exit will hang if the channel is started from the Requester side of the channel. The Requester channel goes into request state, and the Server channel goes into binding state. If the channel is started from the Server side then the channel goes into RUNNING state.
The requester-server channel pair does not start when defined with security exits. The security exchanges loops infinitely when the channel is started from the requester side. The channel starts fine if started from the server side.
[/quote] |
|
| Back to top |
|
|
| zpat |
| Posted: Tue Jul 05, 2011 9:52 pm Post subject: |
|
|
Jedi Council
Joined: 19 May 2001
Posts: 5866
Location: UK
|
| Yes I mentioned this APAR earlier in this thread. This was sender/receiver and the problem was solved without applying a TPF. |
|
| Back to top |
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
