|
|
|
Periapse Linden made changes - 15/Oct/08 10:30 AM
Periapse Linden made changes - 15/Oct/08 10:31 AM
I'm wondering if it may make more sense for people who are visiting a parcel to be limited to their own 38 'personal' urls, even if they come from their own rezzed objects. This would prevent this kind of problem.
Perhaps group membership for the land group could then give access to the full parcel URL pool to others. Just a thought. But on second thought, if you have build on, you also run the risk of someone filling your parcel with prims. so if you are willing to risk that, it seems you should be open to the risk someone uses all your URLs too. This has given me another idea for a suggestion I'm going to open. In the case above, there is a difficult balance between the rights of users WEARING or REZZING objects, and the rights of land owners. Maybe the system should give preference to HTTP_IN servers by age. Where oldest URL_REQUEST is always the highest priority.
Another suggestion, is that since the prim http server can support incoming GET and PUT - I wouldn't mind if the server could only get a single URL that matches the prim UID. you could always send in arguments via GET and design a robust web site inside of your object with a single URL per prim. Issues like this are going to be the key issue for Kelly to manage, as the demonstration for resource management. I don't have a perfect answer here, but Kelly already talks about other avenues for DOS too on this page: http://wiki.secondlife.com/wiki/LSL_http_server/design I think a core goal should be for the transaction to be reliable and provide a clear code upon failure for the external source to re-try. QUOTE:
destiny niles made changes - 18/Oct/08 07:52 PM
People can "DOS" available prims in that case too. So you have to do cleanup. My opinion is that what is missing is not limits per avatar or group, but better reporting on who and what is using urls, such as SVC-3245 so that cleanup can be done.
Implementing per avatar/group/category limits on urls is I think a feature request in the same vein as doing it for prims. It would be a nice feature, but it is a feature request, and not strictly required. And it shouldn't be done without also doing it for prims.
Sue Linden made changes - 13/Nov/08 12:06 PM
Sue Linden made changes - 13/Nov/08 04:34 PM
Sue Linden made changes - 13/Nov/08 04:58 PM
I just wonder, what happens if an attachment that has an URL is dropped on a parcel that has all slots used up? Will the parcel be overused just like rezzed temp objects that are turned into permanent then?
I'll confess I've been unable to attend a few office hours lately, so perhaps this has been discussed and resolved, but no one I've discussed it with has been able to come up with a use case for more than one URL per prim. I just don't see a need for it, as data can be passed in the request to designate where/how it's handled.
The DOS potential extends beyond public sandboxes, where it is certain to be a problem. Since the URL pool is sim-wide, all a griefer has to do is find one parcel with build and scripting enabled, and s/he can block new URLs for the whole sim. If someone can come up with a strong use case for multiple URLs, I'd be interested to hear it; otherwise I think URLs should be limited to 1 per prim; I'd even go so far as to limit it to one per object. Edit: Apparently this has been changed, so that URLs are divided among parcels, according to prim limits. This is good, but just means that griefers will be limited to one parcel at a time. It still has tremendous griefer potential. One use for multiple urls is to provide services to multiple clients on a volatile basis. You assign each client (and by client I mean user) their own URL access to the service, for the duration of it's use. When their use is up, you remove their URL. If it was a common URL, you couldn't do this without removing access to all other clients. Having multiple, disposable URLs is very useful for this application, as active clients can continue to use their URL without it changing every time someone else's access is terminated.
I'm sure I could come up with other scenarios where multiple URLs were useful, but really, it isn't useful for this discussion. The grief potential is incredibly small, as I have already outlined above. Nobody can force an item onto your parcel that you can't remove. I understand what you're saying, but that could be done just as well with URL+key, and expire the key. I don't think the grief potential is small. I could be wrong, but griefers can be very creative. I guess we'll see!
Well, I could be wrong, but must griefers I've met seem to enjoy causing people emotional upset and getting a reaction. This is something more easily achived through screaming boxes, lagging sims, and littering sims with nasty floating particles. Somehow I don't think "haha, I iz uzing yur URLZ!" is going to get much of a reaction out of most people.
 But yes, we will see. Siann, Darien – thanks for the discussion. I'm going to ask Kelly to have one last look at this issue, but I think we're going to resolve it as a feature request that we just don't see the need for at present. I agree with Kelly's earlier statement that URL overloading should be treated the same as primcount overloading.
As for griefing potential, yeah, I can see that sandboxes might be stricken, but anyone who really needs to test their http-in code has options besides agni sandboxes (including going out to aditi). There are use cases for multiple urls:
Yes, it is probably possible to work around a single url on a prim for these cases but given the general resource constraints on scripts (memory size and cpu cycles) simplifying things in this way does actually make some things possible that would have been so cumbersome otherwise as to have been essentially impossible. Additionally this is a test case for the concept of allocating resources to pools based on land ownership in a region, something we are considering expanding to other resources. If you attempt to rez or drop an object onto a parcel that can not support the number of urls the object is using then the object will not be rezed, or will be returned in the case of dropping. As such the parcel will not go over limit. If an object is already on a parcel and attempts to request more urls than are available the request will be denied and no urls granted. The only time objects can possibly get returned is when someone owns multiple parcels and sells one such that after the sale one of the parcel owners (the old owner or new owner) has too many urls being used. In all other cases we simply prevent the actions that would cause you to go over limit. We do need better tools for better information on resource usage, however this is no more a DOS attack vector than simply rezing enough prims to fill a parcel. The same tools we already have for combating that (object return, banning or limiting access to the parcel) will work for this situation as well.
kelly linden made changes - 14/Jan/09 02:04 PM
kelly linden made changes - 14/Jan/09 02:17 PM
Periapse Linden made changes - 14/Jan/09 02:50 PM
Periapse Linden made changes - 14/Jan/09 02:51 PM
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Resolved
Normal
http-in beta: "DOS" for http-in functionality
lets say I have a vendor on my store that allows people to rez things with a very simple script they could render my objects
useless, just by adding this script:
default
{ llRequestURL(); }{
state_entry()
http_request(key id, string method, string body)
{
if(method != URL_REQUEST_GRANTED)
{ llOwnerSay("no url"); llRequestURL(); }if (method == URL_REQUEST_GRANTED)
{ llOwnerSay("URL: " + body); llOwnerSay((string)llGetFreeURLs()); llRequestURL(); }}
}
now I tought about solutions and the best solution I have seen so far is to add a parcel flag that would allow other residents
to open URLS. so they can rez object but not create URLS. just a tought. and basically with a few of those scripts I rendered
the llhttp part useless on the sim... in the case of a sandbox for an example.
that or maybe co-relate the number of open URLS per sim per owner ?