question: money() function

Ok this is my point and I want to make sure its secure enough to use in my script.

I am the creator and owner of a object named 'A'.
When I send this object to someone else he/she will become the owner of it while I am still the creator of it. (duh)

Now I wonder if it is possible to pay the creator when the owner or another avatar pays the object 'A'. For now I can only see this pays the owner and I think its not possible to pay the creator of the object/script?

Ok I did this to solve it.

Included the llRequestPermissions(llGetOwner(),PERMISSION_DEBIT); in my state entry and included the money function like this:

/// This function will always pay the object owner ??

money(key id, integer amount)
{
if(amount != payprice)
{

/// if the owner pays his own object, but price is invalid. the object pays the amout back.

llGiveMoney(id, amount);
llInstantMessage(id, "You paid "+(string)amount+", which is the wrong price, the price is: "+(string)payprice);
}
else
{

/// if the owner pays his own object, and price is right. The object pays the avatar key in the function llGiveMoney.

llGiveMoney("xxx-xxx-xxx-xxx", amount);
llInstantMessage(id, "Right price recieved.";
}
}

I know the script above it working. Everyone who pays the object is paying the owner of it and the owner pays the inserted avatar key. What my question is.. is it possible to those object owners to script a workaround for this so it does not pay with the llGiveMoney() function? Is it a save way to do this?

Security 1: I already noticed that when using llGetCreator( ) in the llGiveMoney() function it has a really easy work around by simpely replacing the script in their own object so I included the parmanent avatar key here instead of the object creators key.

Security 2: I also noticed that when not using the 'run_time_permissions()' it is still possible to get the "Right price recieved" message from the function above. I included this function so owners of the object have to grand permission first before it switches to another state with the scripts.

More things?

Cheers already!

Tho the key representing the creator will never change so you can hardcode it, you could also use llGetInventoryCreator(llGetScriptName()). You're the creator of the script and if you don't give mod perms on it, that will never change even if the script is put in another object with another creator.

As for another way to give money, what do you expect? llGiveMoney() is very clear. G, i, v, e, M, o, n, e, y... Give... Money... In other words, no. There is no llGiveMoveInATortuousWay().

When you pay an object, the amount goes directly to its owner. The only way to divert part or all of it is to take it back from where it went. If the owner doesn't want to see the dialogs, he/she can disable them or at least reduce their numbers in increasing the threshhold at which such a dialog appears.

And instead of giving back all the money the script receives when it's not the right amount, you may think of just giving back the change when there's too much... And refund only when the AV didn't pay enough.

But the most simple way is to fix the price once for all with llSetPayPrice(PAY_HIDE, [price, PAY_HIDE, PAY_HIDE, PAY_HIDE]);

LL advise to always check the amount but I still haven't found the way to pay something else than the price that is written on the button by llSetPayPrice().

Just my 0.02 L$ of the day...

Kaluura: it is necessary to check the amount in the money() event because the SL client is open-source and hence cannot be necessarily "trusted" in the proper security-conscious sense of the word.

If I really put my mind to it, I could create a custom variant of the SL client which did not respect the use of PAY_HIDE as the first parameter to llSetPayPrice().

Plus, there are (or at least, were) some other ways that you could pay an object an amount other than what it's expecting - I guess if the object were a vendor, if you got the money-prompt up for a cheap object and then scrolled round to a more-expensive one? (I'm sure there's reasons why that specific thing might not work now, but it's that sort of issue.)

The owner could keep his/her account empty and insert a script with its own 'money' handler that pays all of the money received immediately into another account. if that happens before your 'money' handler runs (assume that'll happen about 50% of the time), your 'money' handler will not have any L$ to give you. Note that since there is no way to tell if llGiveMoney() succeeded or not, your script will happily continue on its way thinking you (the creator) have been paid.

You could send yourself an e-mail or IM (every once in a while) and check that the amount you SHOULD have been paid matches the amount you HAVE BEEN paid (from your account history), or you could setup a credit account with the vendor's owner and simply track charges rather than transferring actual funds (e.g. a vendor pays for a license to sell a certain number of your product packages). But these are pretty complicated and/or manual solutions (some of which may require resources such as external web servers) that most people don't want to mess with for a basic vendor, so there's really very little to do about this without an enhancement of some kind from Linden Lab.

The other thing to consider in terms of security is obviously the trust of the vendor owners. If you accept debit permissions from a script, you'd DARN WELL better trust that script. That means you really need to assure your customers that their money will be safe in your hands. One way to do this is with good documentation that attempts to show the customer how secure and high-quality your system is. The other way is obviously with your reputation, which is kind of outside the scope of this discussion forum. You can also reverse the trust relationship by giving your system out open-source, but then it is YOU who has to trust the vendor owner(s) not to change or redistribute the script.

Feel better now?

The creator of the script can be changed regardless of permissions, and a script can always be put into a prim with a different creator, so I would certainly avoid llGetCreator and just hard-code the creator's key in it.

The creator of the SCRIPT can be changed? The SCRIPT, not the OBJECT? Without modify permissions? How? If that's true, it should be submitted to LL as a critical security defect.

A fix is pending. I'll say for my suggestion though: it's a choice to rely on just one aspect of the system not being broken instead of multiple parts. If someone finds a way to read your script without permission, they can get secret LL developer attention on it fast.

Quite a cryptic answer, but I'll take it. Hope this one gets nailed down quickly.

And that's what I *always* do, even if I download only clients from LL. LL has proved to be able to release in the wild some very nasty bugs. So... Trust no-one.™

I was obviously sleepwalking on my keyboard. I forgot the end of the sentence.