Should Public access level be allowed auth to Addons

[Pingout]

What version of OpenCollar are you using? OC 8.2.3, Cuffs are OpenCollar Addon Cuff Set V 2.2.2

What behavior did you expect? We expected when the Wearer set her collar to Public that I would be able to use her Addon Cuffs

What behavior did you see instead? Public access Addon Menu request get a "[06:03] OC White Collar: Insufficient authority to access add-ons menu." message

We are curious is this intentional, or is it an oversight?

[Pingout]

oc_addons script line 180 - 188 specifically excludes Public from Addon auth

UserCommand(integer iNum, string sStr, key kID) {
if (llToLower(sStr)==llToLower(g_sSubMenu) || llToLower(sStr) == "menu "+llToLower(g_sSubMenu))
{
if(iNum==CMD_EVERYONE) {
llMessageLinked(LINK_SET,NOTIFY,"0Insufficient authority to access add-ons menu.",kID);
llMessageLinked(LINK_SET,0,"menu",kID);
}
else AddonsMenu(kID, iNum);
}

[Trix7125]

Lets look history why it is there. So some kind auth problem fix.

Per 8.1, if someone on public access (CMD_EVERYONE) clicks the add-ons menu button, they fail auth check without any response from the collar.

Fixes issue #665
Pull: #666

[Pingout]

My initial question: Should Public access level be allowed access to the Addons Menu?
I feel that if a collar wearer, or the owner, decides to set the collar to Public, that everyone should be allowed access to cuff poses.
For example, when a Public person gets a command to kneel, and if the kneel pose has cuff chains associated with it in the Collar notecard, the cuffs will spawn the required chains. But when that same Public person has someone try to access the cuffs through the addon menu they get the error mentioned above.
My questions is not "Why is it doing this?", my question is "Is this the kind of behavior we want?"

[Trix7125]

Yes it sound more logical.

For example, when a Public person gets a command to kneel, and if the kneel pose has cuff chains associated with it in the
Collar notecard, the cuffs will spawn the required chains.

Side question: How to-do i configure note card that kneel pose has cuff chains?
Only the cuffs poses has chain on default.

[Pingout]

One feature of the Addon Cuffs is the ability, using a notecard, to force the cuffs to spawn chains when the collar Wearer is in a collar pose. The free "OpenCollar Addon Cuffs" available at the Headquarters has this feature.
https://opencollar.cc/docs/OpenCollar-Cuffs refer to the section marked Collar Poses

[Surssin]

Ping asked for a comment, so here is my two cents;

It's tricky to navigate as I can see where you might want to grant public use for the collar, but not the cuffs. But then you may also want to grant public use to the cuffs as well. So how do you navigate the two points of view? A setting would be easiest of course, but not always so easy to code in.

Not overly helpful, but I don't know what else to add. I guess if I had to choose, I'd vote that public means public, cuffs included. But that's me.

[tayaphidoux]

authorization level should be configurable on addon side so that the owner/sub can determine access permissions for the addon, otherwise i don't see an issue for some situations that it would be viable to have open access, except that there is little to no security on communications between collar and addon no exclusion to what can communicate to the addon.

[SueCripter]

My first thought on this matter is that public access should give access to registered addons. If one set the collar to public, it means that one want the public to be able to use the collar. The addons should be considered a part of the collar features.

Then it is up to the addons to add further restrictions/permissions if needed.

[mistressohm]

My thoughts are with tayaphidoux on this - as long as the security of the collar and wearer are not compromised, public access should be viable. BUT, careful thought should be given to what an addon's functions are. Cuffs, gags, chastity devices, and stim toys are relatively benign, as they affect the wearer. Any kind of attachment that tries to change relay settings, report location, or spy on local chat would be inappropriate for public access.

…

On Sun, Jun 30, 2024 at 10:15 AM SueCripter ***@***.***> wrote: My first thought on this matter is that public access should give access to registered addons. If one set the collar to public, it means that one want the public to be able to use the collar. The addons should be considered a part of the collar features. Then it is up to the addons to add further restrictions/permissions if needed. — Reply to this email directly, view it on GitHub <#1037 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALSHY5BAHBCBGU2XRMIJL4DZKAOKTAVCNFSM6AAAAABGLLO2V6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCOJYGU4TINJXGE> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[tayaphidoux]

my point is if you do allow public access becarefull of how your addon communicates with the collar the from_collar calls and the to collar calls are generaly public the diffrence is alowing the addon to do llRegionsSay as apposed llRegionSayTo, if the addon is not writen correctly it could be hijacked by another addon, and public access vs your own or your owners authorization could allow for interesting interactions.

[SueCripter]

One solution would be to add an option that lets you toggle if addons should be public or not.

Public Addon settings:

• No - Prevent access to addons with public auth
• Limited - Like "addon limited", or maybe take that a step further
• Full - Like addon limited disabled

And default to No or Limited

Then again, one might want to be able to set permissions on the level of wearer, owner, trusted, group and public separately.
So instead of just having an option for how to handle public, it could be to handle each auth group.

[tayaphidoux]

to make an addon accept every one all you have to change is

UserCommand(integer iNum, string sStr, key kID) {
    if (iNum<CMD_OWNER || iNum>CMD_WEARER) return;
    if (llSubStringIndex(llToLower(sStr), llToLower(g_sAddon)) && llToLower(sStr) != "menu " + llToLower(g_sAddon)) return;
    if (iNum == CMD_OWNER && llToLower(sStr) == "runaway") {
        return;
    }

    if (llToLower(sStr) == llToLower(g_sAddon) || llToLower(sStr) == "menu "+llToLower(g_sAddon))
    {
        Menu(kID, iNum);
    } //else if (iNum!=CMD_OWNER && iNum!=CMD_TRUSTED && kID!=g_kWearer) RelayNotify(kID,"Access denied!",0);
    else
    {
        //integer iWSuccess   = 0; 
        //string sChangetype  = llList2String(llParseString2List(sStr, [" "], []),0);
        //string sChangevalue = llList2String(llParseString2List(sStr, [" "], []),1);
        //string sText;
    }
}

iNum > CMD_WEARER to iNum > CMD_EVERYONE
and that makes this a creator issue not realy an open collar issue.

sorry missed the portion of code ping posted so that does make it a collar issue,
but from a security stand poin it could cause issues.