| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Newbie issue with Exit program |
« View previous topic :: View next topic » |
| Author |
Message
|
| Olorin |
 Posted: Mon Jul 07, 2003 6:37 am Post subject: Newbie issue with Exit program |
 |
|
Newbie
Joined: 07 Jul 2003
Posts: 7
|
Hello all.
I'm a newbie on MQ, so forgive me if I say something wrong :-)
I need to develope a simple exit program that will authorize the user sending a message.
We have a simple Queue Manager, with a queue, and a channel, and, on the client side, we have a simple client application sending messages via MQCONN and MQPUT.
We are running into a couple of problems:
1~ we tried to put the user data (Id, password, etc) in the Channel Definition fields (RemoteUserId, RemoteUserPassword, etc), but apparently the Channel Descriptor (MQCD) that the exit receives is not the same as the one that the client application sent. Actually, it seems that the data that the client app set appears in the message buffer before the actual message body (when the exit is called with Reason MQXR_INIT). We tried to set my exit as a Receive Exit, and as a Security Exit, but we couldn't get that data in either case.
2~ the same problem happens in regard to the results of the exit itself. In other words, we set the ExitResponse to either MQXCC_OK or MQXCC_CLOSE_CHANNEL (if, respectively, the authorization succeds or fails). In the case of a failure, however, we would like to pass back to the client more information (for instance: it failed because of a bad User Id, or Bad password, or we couldn't connect to the database, ...). We originally thought about using the ExitResponse2 field (from the Exit Parameters structure), but it turns out that the ExitResponse2 field, like the ExitResponse, should be set to only one of the pre-defined values. So, I tried to use the ExitUserArea field, but it seems the client does not receive that field back...
Any suggestion?
Thank for your time,
and, in advance, for any idea you may throw this way :-)
Olorin |
|
| Back to top |
|
 |
| clindsey |
| Posted: Mon Jul 07, 2003 7:57 am Post subject: |
|
|
Knight
Joined: 12 Jul 2002
Posts: 586
Location: Dallas, Tx
|
|
| Back to top |
|
|
| Olorin |
| Posted: Mon Jul 07, 2003 8:07 am Post subject: |
|
|
Newbie
Joined: 07 Jul 2003
Posts: 7
|
clindsey,
Thanks for the quick reply.
However, I see that the ic72 sample says that:
| Quote: |
The security exit programs are user written programs which should be written to work as a pair:
a client exit program enabled at the Control Center (written in C)
a server exit program enabled at the configuration manager queue manager (written in java).
|
In our current set-up, the client-side has no exit, so I don't think we can use this sample...
I'll take a look anyway, to see if there's anything useful in it.
Also, our client-side app is in C/C++ instead of Java...
Thanks anyway for the link,
and, if you have anymore suggestions, feel free to append here :-)
Thanks,
Olorin |
|
| Back to top |
|
|
| interactivechannel |
| Posted: Tue Jul 08, 2003 12:47 am Post subject: |
|
|
Voyager
Joined: 20 May 2003
Posts: 94
Location: uk
|
|
| Back to top |
|
|
| Olorin |
| Posted: Thu Jul 10, 2003 8:28 am Post subject: |
|
|
Newbie
Joined: 07 Jul 2003
Posts: 7
|
interactivechannel, thanks for the link.
However, it seems to me that even that exit expects to talk to another exit...
in any case, I've been working on this for the whole week.
The client app connects to the queue, and sends a message just fine.
I have a simple logging exit, and when I use this exit as a Receive exit, it logs a lot of stuff.
Actually it logs all that I would expect. The only problem is that the Receive exit is
invoked 9 times when the client does a single connection + a single put + a disconnect.
So we tried to set the exit as a security exit.
In this case (*joy!*) the exit is invoked only three times.
However --and mind you, the exit's code wasn't changed at all.. we didn't even re-compile it!--
when the exit is set as a Security exit, it fails to see anything in the agent buffer....
This is worrying...
any suggestion/hint/thought?
Thank you in advance,
Olorin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jul 10, 2003 10:00 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| Olorin wrote: |
I have a simple logging exit, and when I use this exit as a Receive exit, it logs a lot of stuff.
Actually it logs all that I would expect. The only problem is that the Receive exit is
invoked 9 times when the client does a single connection + a single put + a disconnect.
So we tried to set the exit as a security exit.
In this case (*joy!*) the exit is invoked only three times.
However --and mind you, the exit's code wasn't changed at all.. we didn't even re-compile it!--
when the exit is set as a Security exit, it fails to see anything in the agent buffer.... |
There's an entire chapter in the Intercommunications guide about the different types of exits, and how often each is invoked and how it is called and when IBM will tell you what the agentbuffer looks like and when it wont.
It will also tell you which exits are supposed to come in pairs, and why. It will even help you decide which kind of exit is right for your logging needs and authorization. Which aren't exactly clear from your message. First you're asking about an authorization, and then you're talking about logging. Maybe you don't want a security exit or a receiver exit. Maybe you want an API exit? (which, unforunately, are documented in a different manual). |
|
| Back to top |
|
|
| Olorin |
| Posted: Thu Jul 10, 2003 10:21 am Post subject: |
|
|
Newbie
Joined: 07 Jul 2003
Posts: 7
|
Jeff, thanks for the reply.
Let me clarify...
our final goal is that of an exit that will authorize/authenticate the incoming messages.
I mentioned logging because while developing, our exit is writing to a log file
(so that we can see what it received, and how to deal with the data).
We looked at the Intercommunications manual, but we couldn't find anything
that seemed to fit our needs...
So, to summarize what I wish this exit to do:
1~ determine if the exit is invoked with actual message data or not (in other words,
when the exit is invoked for a channel initialization/termination, simply accept
the message);
2~ when actual data are present, extract the user data (Id, Psw, ...)
3~ authenticate the user data (I won't go into details on this)
4~ report success or failur (and if failure, the reason why).
Step 2 is the one where I feel we are stuck because:
a~ we tried using the MQCD fields to pass the user info, but the MQCD
instance that the exit receives from the MQ server is NOT the same as
the one that the client sent;
b~ we tried marking up the user data and prepending them to the actual
message body, but this solution has too much overhead if the exit is a
Receive exit (we send 1 message, the exit is invoked 9 times... we have
to parse through the agent buffer 9 times to try and find the marked-up
user data..), while if we use the exit as a Security exit we simply can't get
the agent buffer (with the marked up user data)....
I hope this makes a bit more sense...
...I'll keep on looking, but I got a fealing I'm doing something wrong...
Thanks in advance for any further suggestion!
..BTW, I know that this is not the most typical scenario for using MQ...
but -alas!- what can I do if this is the design they passed me :-)
Thank you,
Olorin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Jul 10, 2003 10:24 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
Can you explain why you don't want to write exits in pairs, like a normal Security exit?
Can you clarify if you are trying to authorize the *message*, or the *sender of the message*? |
|
| Back to top |
|
|
| Olorin |
| Posted: Thu Jul 10, 2003 10:38 am Post subject: |
|
|
Newbie
Joined: 07 Jul 2003
Posts: 7
|
Jeff,
I must develope a single exit (instead of a pair) because of project requirements... (long long story :-)
What we need to authenticate is actual the user sending the message, but
we can't rely upon system identities. What we have is a client application
that gathers the user-related information (User ID, password, etc), and
bundles it up with the actual message body.
As I said, we are trying to figure out which one is the best way for us to
send this user-related info to the server (and hence the exit).
Once the exit gets the info, it will authenticate the user.
Actually is much more complicated than that, but these are the nuts and bolts...
Olorin |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jul 11, 2003 6:29 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| You may want to look at an API exit. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Fri Jul 11, 2003 6:29 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| You may want to look at an API exit. |
|
| Back to top |
|
|
| SnowDragon |
| Posted: Wed Feb 11, 2004 8:22 am Post subject: api exit for logging parameters |
|
|
Guest
|
Hey Olorin,
Would you mind sharing the logging exit api you used for testing?
I also need to research the actual contents of the parameters to the API calls so I know what can I extract.
Some more general questions:
1) Is it possible to extract the IP Address\DNS name of the message sender from the server API exit? (context data)
2) Is it possible to write a client side API exit? How does one register this exit with the client queue manager?
Thanks. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Wed Feb 11, 2004 8:30 am Post subject: Re: api exit for logging parameters |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| SnowDragon wrote: |
| 2) Is it possible to write a client side API exit? How does one register this exit with the client queue manager? |
What's a "client queue manager"? There is no such thing, as far as I know.
You can, however, use the API exit to monitor client API calls. The API exit is registered to the queue manager that the client is connecting to, and then the API calls that the client agent makes will invoke it just like all other API calls.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| Olorin |
| Posted: Wed Feb 11, 2004 8:38 am Post subject: |
|
|
Newbie
Joined: 07 Jul 2003
Posts: 7
|
SnowDragon,
I wouldn't mind sharing the exit,
*but* I have not developed the PAI exit at all :-)
We ended up working with security exits,
based on the sample cited above in the thread.
However, we are still working on this since we *still* have issues.
As far as simple logging, and exploring the content of the
parameters passed to the exits (regardless of the exit type),
I suggest checking the samples provided by IBM for each exit type.
That's, in fact, what most of them do: logging (plus, in some cases, encryption and decryption).
As far as your specific questions, as I said we did not develop API exits, but I simply researched them, so I can't help you much, sorry. But here's
what I can tell you:
1~ I think that the API Exits receive a structure that should include the identity of the user sending the message. In the case of security exits, this is the MQCD structure; I'm not sure of the structure that the API Exits get, but there should be something similar.
2~ I think that API Exits have a main entry point such as:
| Code: |
void MQENTRY EntryPoint ( PMQAXP pExitParms
, PMQAXC pExitContext
, PMQLONG pCompCode
, PMQLONG pReason
)
|
(BTW, the ExitParms structure might be the one with the user ID...)
and in that method you can register the method to intercept the specific MQ API you wish to intercept. For ex:
| Code: |
MQXEP ( pExitParms->Hconfig
, MQXR_BEFORE
, MQXF_GET
, (PMQFUNC) GetBefore
, NULL
, pCompCode
, pReason
);
|
to have the exit call the GetBefore routine before processing an MQ GET request.
HOpe this helps, but, as I said, I didn't do too much with API Exits since they didn't seem to proporse a feasable solution to our problem.
F.O.R. |
|
| Back to top |
|
|
| SnowDragon |
| Posted: Thu Feb 12, 2004 12:21 am Post subject: |
|
|
Guest
|
I ended up trying to use the amqsaxe.dll exit sample (not working yet but I hope I'm getting there) which really does most of what I wanted.
As for client side exit I'll try to clarify what I need:
I need to know the IP Addresss\DNS name of the message sender (the client).
One way is to trap the MQPUT with api exit *but* that's assuming the call contains this data (which I didn't see anywhere in the docs).
Another way would be to somehow sit on the client end where I know the IP and just trap the MQPUT on the caller machine, but from your answer I understand there is no client entry point to hook.
Ok, I'll dig into it furthur, thanks for the help. |
|
| Back to top |
|
|
|
|
|
  |
Goto page 1, 2 Next |
Page 1 of 2 |
|
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
|
|
|
|
