[Opensim-dev] Parcel Access Enforcement

Melanie melanie at t-data.com
Thu Apr 10 15:56:35 UTC 2014


No biting needed :)

Debug output is a pretty good start and you did answer my concern
when you mentioned the intermittent nature of the issue.
I was worried that this would lead to a refactoring frenzy, possibly
breaking even the parts that do work, but the fact that it's not
consistently reproducible means that you're doing the proper
debugging already.

- Melanie

On 10/04/2014 17:52, James Stallings II wrote:
> So, Melanie, I'll bite: What do you suggest for 'proper debugging' in this
> context?
> 
> 
> On Thu, Apr 10, 2014 at 10:25 AM, James Stallings II <
> james.stallings at gmail.com> wrote:
> 
>> The only code I'm affecting the local copy on my server; it isn't as if
>> I'm going to break break the central repo back to 2006. Hell, I don't even
>> have commit. And FWIW, last I hear adding log statements to code is a valid
>> tried and true debugging method.
>>
>>
>>
>>
>>
>>
>> On Thu, Apr 10, 2014 at 10:23 AM, Melanie <melanie at t-data.com> wrote:
>>
>>> I'm not even being defensive. I just don't like the idea of poking
>>> code with a sharp stick instead of debugging it properly.
>>>
>>> - Melanie
>>>
>>> On 10/04/2014 17:20, James Stallings II wrote:
>>> > "Maybe a good starting point is to see what you would like that doesnt'
>>> > work before you go and fix things that..."
>>> >
>>> > Actually, that *is* where I began.
>>> >
>>> > My user reports various failures, which are repeatable on the running
>>> > regions. No amount of reconfiguration predictably affects the
>>> experience on
>>> > the regions.
>>> >
>>> > We do have a couple of regions that seem to work perfectly, including
>>> that
>>> > which I'm working with; it started working after I completely replaced
>>> the
>>> > OpenSim.ini with one that was identical excepting the http_listener
>>> > specifcation. Unfortunately, repeating this process with the same
>>> > OpenSim.ini on a different region that doesn't work did not produce a
>>> > region that does.
>>> >
>>> > To say that it works intermittently is a bit of an understatement;
>>> though
>>> > it does seem that once it begins working it continues to do so.
>>> >
>>> >
>>> > Try not to be so defensive Mel; I'm not attacking you or your work, I'm
>>> > just attempting to figure out what's happening on these regions. I have
>>> > eliminated everything I can find but the code, which I am told by
>>> others is
>>> > not to be trusted as fully functional; and I am not afraid to get in and
>>> > get my hands dirty.
>>> >
>>> >
>>> > Cheers
>>> > James
>>> >
>>> >
>>> >
>>> > On Thu, Apr 10, 2014 at 10:10 AM, Melanie <melanie at t-data.com> wrote:
>>> >
>>> >> The code for parcel access works, as far as I'm aware. It was
>>> >> originally fixed in Avination and that should have been donated to
>>> >> OpenSim a long time ago. Maybe a good starting point is to see what
>>> >> you would like that doesnt' work before you go and fix things that
>>> >> aren't broken.
>>> >>
>>> >> Melanie
>>> >>
>>> >>
>>> >> On 10/04/2014 17:05, James Stallings II wrote:
>>> >> > Subsequent work (instrumentation to Scene) shows that the permissions
>>> >> > checking code is also being called twice there.
>>> >> >
>>> >> > Cheers
>>> >> > James
>>> >> >
>>> >> >
>>> >> >
>>> >> > On Thu, Apr 10, 2014 at 9:30 AM, James Stallings II <
>>> >> > james.stallings at gmail.com> wrote:
>>> >> >
>>> >> >> After some further exploration, I have seen where the method calls
>>> >> taking
>>> >> >> precedence from out of Scene are handling ViaLogin; but they are
>>> also
>>> >> doing
>>> >> >> some of the same lifting performed in the Land Management module.
>>> This
>>> >> >> seems to be duplication of effort, if not duplication of code; and
>>> is
>>> >> >> certainly less elegant than I would hope to find in our codebase
>>> (in an
>>> >> >> ideal world ;)
>>> >> >>
>>> >> >> This is likely the result of the ad-hoc nature of the development
>>> life
>>> >> of
>>> >> >> the project over the years; I can see the scene code being a good
>>> deal
>>> >> >> older than the Land Management module.
>>> >> >>
>>> >> >> I'll be working with this throughout the day, hoping to improve the
>>> code
>>> >> >> as I'm able; your thoughts, advice and commentary are solicited and
>>> >> >> appreciated.
>>> >> >>
>>> >> >> Cheers
>>> >> >> James
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> On Thu, Apr 10, 2014 at 9:01 AM, James Stallings II <
>>> >> >> james.stallings at gmail.com> wrote:
>>> >> >>
>>> >> >>> Greetings Devs :)
>>> >> >>>
>>> >> >>> I have a use case that requires the unlikely and less than popular
>>> >> parcel
>>> >> >>> permissions access control featureset.
>>> >> >>>
>>> >> >>> Historically speaking, this has not been an area of development
>>> that
>>> >> has
>>> >> >>> seen much love, and understandably so; none of us are particularly
>>> >> >>> interested in fully duplicating the operational envelope of the
>>> Second
>>> >> Life
>>> >> >>> experience. That coupled with the ability to deploy regions at
>>> whim,
>>> >> it is
>>> >> >>> no wonder no one wants to involve themselves particularly deeply
>>> with
>>> >> >>> making this work properly.
>>> >> >>>
>>> >> >>> That being said, I have a need at present, and there is also the
>>> simple
>>> >> >>> fact that we have a dearth of UI components in the viewer we may
>>> well
>>> >> never
>>> >> >>> get shut of, and a lot of of unfinished and/or unpolished code in
>>> the
>>> >> repo
>>> >> >>> that touches on this functionality.
>>> >> >>>
>>> >> >>> The short story is, it may be above the waterline, but there is a
>>> hole
>>> >> in
>>> >> >>> the boat, and one of my users is driving it headlong into the surf.
>>> >> >>>
>>> >> >>> So much for metaphors.
>>> >> >>>
>>> >> >>> I have heard a variety of conflicting reports about the state of
>>> this
>>> >> >>> part of the codebase; some say it works well; others say it should
>>> not
>>> >> be
>>> >> >>> counted on to work at all. The commit logs tell the tale that some
>>> have
>>> >> >>> taken an interest and are working diligently to eliminate certain
>>> bugs;
>>> >> >>> unfortunately, the work in progress has not yet brought the
>>> >> functionality
>>> >> >>> into a state where it is yet useful, at least according to my
>>> testing.
>>> >> >>>
>>> >> >>> I'm not unwilling to undertake the work needed to bring this
>>> situation
>>> >> >>> into a more satisfactory light; indeed, I've already begun, and I
>>> need
>>> >> only
>>> >> >>> a little guidance today.
>>> >> >>>
>>> >> >>>  I have thoroughly instrumented the method "public void
>>> >> >>> EventManagerOnAvatarEnteringNewParcel(ScenePresence avatar, int
>>> >> >>> localLandID, UUID regionID)"
>>> >> >>> in the land management module, and was immediately confronted with
>>> a
>>> >> >>> couple of surprises:
>>> >> >>> First, when the code is called at all, it is called twice; and as
>>> far
>>> >> as
>>> >> >>> I can tell, it is called only after a successful login has been
>>> >> completed.
>>> >> >>> Neither does it seem to be called when an avatar teleports into the
>>> >> region.
>>> >> >>>
>>> >> >>> Instead, the method "public bool TestLandRestrictions(UUID
>>> agentID, out
>>> >> >>> string reason, ref float posX, ref float posY)" is called from
>>> >> >>> "OpenSim/Region/Framework/Scenes/Scene.cs" and
>>> >> >>> "OpenSim/Region/Framework/Scenes/ScenePresence.cs", and mediates
>>> >> (rather
>>> >> >>> less than consistently) whether the avatar is allowed into the
>>> parcel
>>> >> on
>>> >> >>> the region.
>>> >> >>>
>>> >> >>> Being aware that there are several ways for an avatar to enter a
>>> >> parcel,
>>> >> >>> which I will leave off enumerating at present, I would suggest that
>>> >> perhaps
>>> >> >>> I have some misapprehensions as to the proper stages of
>>> authentication
>>> >> at
>>> >> >>> login-time.
>>> >> >>>
>>> >> >>> So my question is this: should both of these functions come into
>>> play
>>> >> as
>>> >> >>> an avatar enters a region (and consequently, a parcel)? or should
>>> >> there be
>>> >> >>> a single methoid conducting these presence permission checks?
>>> >> >>>
>>> >> >>> Please advise at your convenience :)
>>> >> >>>
>>> >> >>> Many thanks and cheers
>>> >> >>> James/Hiro
>>> >> >>>
>>> >> >>>
>>> >> >>> --
>>> >> >>> ===================================
>>> >> >>> http://osgrid.org/
>>> >> >>> http://simhost.com
>>> >> >>> http://twitter.com/jstallings2
>>> >> >>>
>>> >> >>>
>>> >> >>
>>> >> >>
>>> >> >> --
>>> >> >> ===================================
>>> >> >> http://osgrid.org/
>>> >> >> http://simhost.com
>>> >> >> http://twitter.com/jstallings2
>>> >> >>
>>> >> >>
>>> >> >
>>> >> >
>>> >> >
>>> >> >
>>> >> > _______________________________________________
>>> >> > Opensim-dev mailing list
>>> >> > Opensim-dev at lists.berlios.de
>>> >> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>>> >> _______________________________________________
>>> >> Opensim-dev mailing list
>>> >> Opensim-dev at lists.berlios.de
>>> >> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>> >>
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > Opensim-dev mailing list
>>> > Opensim-dev at lists.berlios.de
>>> > https://lists.berlios.de/mailman/listinfo/opensim-dev
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>
>>
>>
>> --
>> ===================================
>> http://osgrid.org/
>> http://simhost.com
>> http://twitter.com/jstallings2
>>
>>
> 
> 
> 
> 
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de
> https://lists.berlios.de/mailman/listinfo/opensim-dev



More information about the Opensim-dev mailing list