[Opensim-dev] Parcel Access Enforcement

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

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://opensimulator.org/pipermail/opensim-dev/attachments/20140410/dbafe755/attachment-0001.html>

More information about the Opensim-dev mailing list