Getting key of the rezzing object

I have an object (attachment) rezzing another object from its inventory. The parent has an object_rez event handler, which gives it the child's key. This lets me set up a tightly constrained listener to listen just to that child object.

I want to do the same on the child's side, but can't see a simple way. The client gets a param from its rezzing parent - which I can use as a channel, but to really lock it down I'd like to get the parent's key.
I can have the parent whisper its key on one channel, then have the client close that listen and open up another, but that seems a long way round. Am I missing a better way?

Granted with 2 million channels to choose from who's really going to care.. I'm just curious now.

Yes, you'll likely have to take the long way around, as I don't think on_rez is passed that kind of data.

It shouldn't hurt to open a randomized channel. Since the chances of being "hacked" at this phase are so small, you should be okay.

You can check that the current owner and whoever's telling you who your parent is are the same.

Additionally, if you're extremely paranoid, you can also sign your message with an MD5 sum, and a private key.

The private key can be generated from the location/time/date/rez paramater/hardcoded value or any combination thereof.

This would make it effectively impossible to trick your new object into thinking someone else is its parent

Thanks for your suggestions and insight.

I was coming at this from the point of view of basic best practices - don't listen for anything more than you need - as much as from the point of view of security. Yes I'm being anal but no-ones paying me by the hour so I'll execute my perogative to overthink the problem and call it leisure :)

Both client and parent have the same function to generate a channel # from a key, so when the client is rezzed it generates the channel from its key, and the manager/parent can do the same as it gets the key back in the object_rez event. They handshake with a simple whisper. I get the parent's key from the first listen event so I'll store it, switch state and open a new listener constrained to the key & channel.

I've noticed that there's a problem with using 'say' to transmit keys, it sometimes seems to silently fail, and while I haven't tested my theory I think it's a valid one. The problem is that some keys (especially Av keys for some reason) start with number instead of letters. So it you try to whisper one of those keys on channel 1 for instance, the command passed to say would be /13fadc-323ds- so on.. so it would really end up saying fadc-323ds- on channel 13.. hence your listen would never hear it! My idea of a fix would be to append a ',' before the key, then parse it with llCSV2List or somesuch.

Like I said, I haven't tested this, but if you encounter a problem of your rezzer sometimes not hearing the key of the rez-ee, give this a try!

Just add a space...

/1 34567... will talk on channel 1