llListen and access groups

This post is more of a cautionary note than a question . I would add it to the llListen page on the wiki if I could, but even then I wouldn't really know how .

I was making a listen event respond only to commands issued by certain avies, and originally I naively just compared the name given by the event against the authorized list until I realized later on that someone could simply make an object, name it and have it say the commands.

I know it's a trivial thing and the hacks page on the wiki has a section on it, but since my alt succeeded in lock/unlocking my rental house by "impersonating" me it seems I'm not the only one who made the mistake so an explicit note about it there might make sense .

The hacks page proposes an isAgent() function, where my own first solution would be to simply to replace the supplied name with llKey2Name(key). Is there an (dis)advantage to either one?

Probably the best way to work around that, is instead of checking against names in the access list, to check against keys. Keys cannot be faked.

How do I add the keys to the access list, you ask?

You could create an object that just gets your key and llSay it or llOwnerSay it to be pasted directly into the script.

The advantages to this, is that the keys would be hardcoded in, no one could trick the script into adding thier key to the list, and the list would survive through resets.

The disadvantages would be the extra work of copying and pasting the keys into the script manually, and double checking that you didn't make a mistake.

Another route would be to have the Owner of the script set the object so that the next person who touches it, or whispers a secret command to it on a secret channel gets thier key added to the list automatically.

The advantages to this is that it's automatic, and doesn't require messing with the script every time you wanted to add someone. You could even have a function allowing yourself the ability to delete someone easily.

The disadvantages would be making sure someone else doesn't touch the object or say the secret password before the intended person who you wished to add. Also, the list would be lost on server reboots and script resets.

Everything Aakanaar said but use the script on this page to access w-hat's name2key database. Type in the name of the avatar you want to add and it will return thier key:

C:\Documents and Settings\Owner\Desktop\LSLWM 10-5-2006\llHTTPRequest.htm

um.. heh.. that's not going to work well. Look up a Name2Key script. there are several in this forum, and I think there may be one on the LSL Wiki. You can also check http://w-hat.com/name2key for more info.

I think you misunderstood (and I didn't post a link to the hacks page on the wiki so really my fault ).

It actually reads the authorised list off of a notecard, and the people on the list would change frequently, and to complicate matters multiple people can add/remove someone, so doing it without a notecard would really just be a whole lot more work (for me) and make it far less easy to use (access to the notecard is controlled by group so I don't need to bother with that ).

My actual question was about (http://www.lslwiki.com/lslwiki/wakka.php?wakka=hacks):

integer isAgent(key id)
{
    return (llGetAgentSize(id) != ZERO_VECTOR);
}

Because llKey2Name(key) seems like a far more logicial choice than llGetAgentSize and I just wondered if it was personal preference or if there was good reason to do it that way.

Sorry again for the confusion .

The problem with llKey2Name is that the agent must be in the same sim. This may seem evident, but I can click on objects from the next sim over easily. Even if the object is not very near the sim border. This would break that usage of llKey2Name.

You simply need to make sure the speaker is an agent and not an object. or use Keys instead of names.

Ooooops my bad. I have the wiki data base on my computer and tied into Scite. Here is the name2 key script in the wiki that ties into the w-hat site:

http://www.lslwiki.com/lslwiki/wakka.php?wakka=llHTTPRequest

The same is true of llGetAgentSize, it only works if the avie is on the same sim.



You're right . I was just assuming that since llKey2Name is under the agent category it wouldn't work on objects. I feel stupid now . Thanks!

Thanks for the link, but it just seems like too much unnecessary work to get a key when you have it already, all I needed to know was whether the key is an avie key, or an object key .

Sorry, you got mixed up. That link isn't for getting the key. It actually works both ways. That link lets you submit a name to get someone's key, but it also lets you use a script to submit a key and get a name.

In other words, it's a Key2Name function that works across sim borders, but requires a call to a web page. It also requires that the person who's key you're trying to search for is in the database.. which most are, but some might not be, especially newer players.

I tried a few random ones on the site and some didn't turn up, the oldest of which signed up in May, so I'd still have to fall back which means there isn't really much point to using it in the first place unless I'm just missing something.

It seems that as long as the agent is a child agent of the sim the object is in, it'll work fine, I wasn't really concerned with that case anyway .

As Aakanaar LaSalle stated the 'secure' way is to use Keys not names.
Its easy enough to verify that the key entered is correct using the llKey2Name function to dump out the name of the AV being added as a check.

The other thing is that I presume you are using chat driven locks. Use touch instead and the problem goes away since objects cannot activate the touch event.

This was an interesting thread, but I'm uncertain about how one would set up the actual listen for a group like this. llListen can be filtered by a key, but not a list of keys. Would one need to create a listener for every permitted avatar?

I'm working on something that needs to react to multiple voice commands over a period of time, and I don't want to create too much lag if it can be avoided.

The filtering wouldn't be done in the llListen function, it'd be in the listen event. The event captures the key of whomever has spoken to it, so you just add something like this inside the event:

listen(integer number, string name, key speakerKey, string message) {
  if(llListFindList(authorizedKeys,[speakerKey]) != -1) {
    // do stuff here
  }
}

So the listen function is basicaly accepting all keys, all names, etc but the event will only act on the message if the speaker's key was on an authorized key list.

-Atashi

No, only have one listen then check against the allowed list in the script.

list Allowed = []; // Populate with keys of allowed individuals

integer IsAllowed(key id)
{
    integer result = FALSE;
    integer Index = llListFindList(Allowed, [ id ]);

    // Alwasy allow the owner
    if(llGetOwner() == id) Index = 9999;
    if(Index >= 0)result = TRUE;
    return result;
}

default
{  
    

    // For a touch
    touch_start(integer total_number)
    {
        key id = llDetectedKey(0);
        if(IsAllowed(id)
        {
        }
    }

    // Or for a listen
    listen(integer channel, string name, key id, string message)
    {
        if(IsAllowed(id)
        {
        }
    }
}

You could also have a group for your renters (a good idea anyway), put the object in the group (in object's edit->general tab), and use llSameGroup(id) to see if the person is in the object's group.

This avoids you having to enter the names of eligible people, as you probably would with Newgate's suggestion.