llGiveMoney() without PERMISSION_DEBIT

As a relative newcomer, I've been whiling away the hours reading the wiki and designing my first product. Unless I have the wrong end of the stick, it appears that the only way to have a script pay money to someone other than the object owner is by having it request PERMISSION_DEBIT.

The problem with that is that by granting PERMISSION_DEBIT, the user is giving the script unfettered access to their entire account. It gives the script permission to pay as much as it wants to whoever it wants.

I would find it very useful to be able to call llGiveMoney() without first obtaining PERMISSION_DEBIT. Then, instead of being presented with an open-ended dialogue saying "An object owned by X would like to take Linden dollars(L$) from you {yeah, right}", the dialogue would say "Object x would like to transfer L$50 from your account to A.N. Avatar"

Would anyone else find this useful? I think I might add it as a feature request.

Your solution doesn't take into account that requiring approval for every transaction is unworkable when the debtor isn't online.

What would happen on your case if you had a vendor setup that needed to give change if someone overpaid, or a scripted sploder that gave prizes out, but you weren't online? Nobody would get paid? Everybody who was supposed to get paid would have to wait until you came online and OKed everything?

Unfortunately, PERMISSION_DEBIT is a necessary evil.

Hi Jaques. I think I'm coming at this from a slightly different angle than you. I agree, that in the cases you mentioned, PERMISSION_DEBIT is just what is required. I wasn't suggesting that PERMISSION_DEBIT be replaced with the function that I described, rather that both options be available.

The idea I have in mind is a kind of subscription service. The user purchases a HUD device which has a limited lifetime. Once it reaches the end of its life, the user is given the opportunity to renew the subscription. The simplest way to do that would be to allow the HUD to transfer money directly from the user's account. At the moment, I can't see any way of doing that.

There seem to be two distinct types of product that need objects to be able to make payments on behalf of their owner. In the first kind of product, the ones you described, the owner wants to give the product permission to give money away, on a regular basis, to unknown recipients. In the second kind of product, the one I described, the owner wants to occasionally give specific amounts to a named recipient.

I think both these models are needed in SL. But, as far as I can see, we currrently have the former but not the latter.

You are correct in your assertion that the model you are suggesting doesn't exist. It just can't be pulled off now. I wish something like this was doable, but currently, it isn't.

This is also why the web-based systems all require you to go to one of their in-world ATMs and prepay an amount.

Why not just do this:

When the user needs to renew the subscription, request PERMISSION_DEBIT and, if granted, llGiveMoney to make the payment, then do a llRequestPermissions(llGetOwner(),0) to release the debit permission.

There is also nothing stopping you from making it such that the script pops up a dialog 'I need to renew your subscription..." and only actioning the llGiveMoney at that point if they agree.

Thanks for the suggestions. The ideas that you've come up with are similar to the way I currently have it implemented. But, as I see it, there are two major problems with this way of doing things:

1. The user has to click "Yes" to that scary looking message saying that the object "... would like to take ($L) from you." Most people will be understandably dubious about doing so.
   

1. This system genuinely is open to abuse. If people become accustomed to clicking "Yes" to that message, then it's not going to be long before some crook comes along and markets a product to drain the account of anyone who uses it.
   

You never grant debit perms to an object you dont trust.

The problem here is: Which objects CAN you trust?

None, except your own, or those that are open source and whose code you understand - period. All other systems should use money() events and the RightClick->Pay function.

That's the problem. In my situation, I want the object to make a payment from the owner to a third party. The only way to do that is by the object requesting PERMISSION_DEBIT.

Instead of asking for open-ended permissions, I want the object to be able to request permission to make a one-off payment of a specified amount to a specified user.

Unfortunately, I can't use RightClick->Pay because that won't allow the object ot make a payment to anyone other than the owner.

I attempted a solution to this here:

/54/63/158231/1.html

It's largely for vendors and other objects that pay change or prizes, but it could be adapted to allow fixed payments with one-off permission, too.

Yeah, I think I see what you are saying now. In retrospect, I think that would be a good addition. Basically something like llGiveMoneyLimited(key kAgent, integer iAmount), which asked for permission to give that specific amount to another user.

The problem is how to implement it in an event-based system. Obviously, the script needs a way to confirm that the user permitted it to occur, and it will have to be done via an event, since you can't block the script waiting on the client to approve/deny it. As such, it will need an additional event handler (money_given(kAgent, iAmount), for example). You also cannot trust the client that it will give the amount you requested, if it uses the existing pay mechanism. If it is completely server/sim-based, then you can.

Sounds like something you should request in the Feature Voting Tool, or in the Feature Suggestions forum.

Permission debit, and "unfettered access" is absolutely needed. how can a vendor give change, casino game make a payout, etc... However, there is an easy fix for this..

Let's say that u have 1,000,000 L's, and you dont want to grant full access to the account. The solution to the problem is simple. Create an alternate basic account, and use that account as a bank, say, pay 990,000 L's to that avatar, and then have 10,000 L's in your account for operating purposes. That way, should you get dinged, it wont be for every penny. Ever heard of not keeping all your eggs in one basket?

Johan,

Re-read the posts above; he clarified that it should be an addition, not a change, to the way debit permissions work now.

I think we all understand the importance and need for the existing debit system.

I think Johan has a good idea for protecting yourself against malicious code--this solution is a good temporary fix for residents until a secure modification in code can be implemented.