[JIRA] Commented: (SVC-5037) Simple way to validate payments from in-world
darling brody (JIRA)
no-reply at lindenlab.cascadeo.com
Thu Nov 12 18:57:02 PST 2009
[ http://jira.secondlife.com/browse/SVC-5037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=146367#action_146367 ]
darling brody commented on SVC-5037:
Thats an interesting idea. Probably should have it's own JIRA so the lindens can chose which method to implement. If they don't like my idea they might not read your comment.
I wanted to suggest a system that would not have the problems that have stalled the implementation of the other methods that revolve around returning a valud from the llGiveMoney function. The one I have suggested shouldnt require very much work on their part to implement.
It might however require a permission to be given before you can access the URL. Perhaps HTTPRequest can refuse to load the page unless the PermissionDebit is given. If you trust an object to pay money, then you can trust it to read the transaction history too.
PermissionDebit would prevent people handing you an object that could be secretly relaying your transaction history to them.
An alternative might be a PERMISSION_HISTORY and a "string llReadTransactionHistory(string DateTime)" function. Which is what we are simulating by way of the HTTPRequest function.
> Simple way to validate payments from in-world
> Key: SVC-5037
> URL: http://jira.secondlife.com/browse/SVC-5037
> Project: 2. Second Life Service - SVC
> Issue Type: New Feature
> Components: LSL HTTP
> Affects Versions: Mono Beta, 1.21.0 Server, 1.22.1 Server, 1.22.2 Server, 1.22.3 Server, 1.22.4 Server, 1.23.0, 1.23.4 Server, 1.24 Server, 1.25 Server, 1.26 Server, 1.27 Server, 1.30 Server, 1.32 Server
> Reporter: darling brody
> Priority: Critical
> This issue is a proposal to resolve SVC-595 though a non-LSL means.
> Right now people are cobbeling together PHP/CURL scripts to load the transaction page and import it in world for payment validation in vending machine networks.
> Many other people do not have the means to do this themselves and simply suffer the lost sales from scammers.
> Additionally whenever the webpage is altered all the vending machines fail to deliver because the web interface is made for humans who are able to cope with format changes, unlike scripts.
> Create an offical domain/url to load the transaction page from the LSL HTTPRequest command that returns the history for the prim object owner.
> eg: MyHistory.Secondlife.com would return the details for the in-world object owner in a CSV format.
> *Suggested format*
> TransactionID, DateTime, Region, Destination/Source, Value, Balance
> 8e9fa249-9c46-04de-f243-8264eed3391c, 2009-11-12 16:37:48, Quantum, Darling Brody, 500, 1012, <line break for jira only>
> 72c63e55-8174-a5b3-c5f8-c76699e69c9c, 2009-11-12 16:15:34, Quantum, SYSTEM, -10, 512,
> The above two examples show money going in and out for both avatars and system events such as paying for an upload.
> The Debit/Credit colums are combined into the Value column with a negative number being used to represent a Debit.
> This format gives all the information needed in a convenient format for transaction validation. A delivery server will look for a transaction at the same time, region, and amount for the requested delivery item. The delivery server then sends the product and records the TransactionID to avoid sending a second delivery for that single payment.
> URL should only respond to requests from a region's IP.
> URL should only return details for the owner of the object.
> No password or username required. (It is not safe to store them in LSL scripts due to permissions exploits)
This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://jira.secondlife.com/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the Jira-notify