[Opensim-dev] Parcel Access Enforcement

James Stallings II james.stallings at gmail.com
Thu Apr 10 15:20:44 UTC 2014


"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
>



-- 
===================================
http://osgrid.org/
http://simhost.com
http://twitter.com/jstallings2
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20140410/409b8311/attachment-0001.html>


More information about the Opensim-dev mailing list