Well, I don't grok the mapping service, would that not be just another way of accessing the inventory by bypassing the region? In current commercial, "secure", trusted grids, the inventory server is not accessible at all, there are only region-shaped holes in the firewall.
As for CAPS, I'd say LL space. If another viewer wants to use them, I feel duplication of code is more acceptable here than having that in the region. It _is_ a means to talk to a viewer after all. If you can make a case for CAPS being in the region, you can also make one for UDP. The line needs to be drawn somewhere. Melanie Diva Canto wrote: > I actually didn't explain Capabilities exactly as they can be used in > the extreme. You will see that this can be used also when you have the > inventory server behind closed doors. > > A capability URL doesn't need to be a direct web service. It can be an > indirect pointer. So you have the public URL that you give out to the > client, and when that is invoked it finds a capability mapping service > that finally invokes the capability function provider. > > I don't think I want to do this right now. So yes, all those URLs should > be configurable. > > The bigger issue I'm debating is how all this should look like in the > code. We all know we don't know where to put CAPs :-) I'm hoping this > will finally give it a natural place to be, but I need to think a lot > more. One thing's for sure: CAPs is an LL Viewer thing and as such it > should be under LLxxx. It's very unlikely that other viewers will use > capabilities. (although the more I think about it, the more similarities > I see with OpenID Tokens...) > > > Melanie wrote: >> Well, if FetchInventoryDescendents works better over CAPS, then we >> can try using that. Now, that would serve another purpose beyond >> your intended trust issue: >> >> Currently, inventory is fetched by the region en-bloc, rather than >> being fetched only on demand. There isn't even a function to fetch a >> single item by UUID. >> >> Now, here is what I found: >> >> - If an item is given to a user while that user is offline, the user >> needs to clear cache to see it >> - If an item is given to a user while that user is in another >> region, the item will not show until a relog & cache clear >> >> You just supplied a very important bit of information, namely that >> the viewer sends SendInventoryDescendents over UDP only after a >> cache clear, but over CAPS it's sent all the time. >> >> So, CAPS would seem to be the solution to this issue. >> >> Now, here it goes, again: >> >> There are grids that are set up to have an inventory server that is >> inaccessible to the viewer. So, while I'm, of course, not opposed to >> your approach of lettign the viewer talk to the inventory server, >> that needs to be optional. The inventory server is not secure enough >> to be open to the internet! Not for the fledgling commercial >> offerings like LCO. >> >> Also, this highlights a new, additional reason to have a function >> like "get item by uuid" on the inventory server interface. On >> cross-region gives, the region of the receiving agent receives a >> message (via IM) containing the item ID. In order to send the bulk >> update message that is needed to make the viewer actually see the >> item, it needs to first fetch it. This is not an issue if giver and >> receiver are in one region, because the item is already in the >> region's inventory cache, but if it;s a different region, it doesn't >> have that item and currently has no way to request it, short of >> reloading that user's complete inventory! >> >> So, maybe, as a side effect, this problem can be solved, since such >> a "fetch item to region by UUID" function will be needed for that >> scenario, too. >> >> For open grid offerings, I see some added security against regions >> corrupting user inventories, for all grids, I see some advantage in >> memory consumption, because the full inventory fetch on region entry >> is removed by it, and also maybe a chance to make cross-region item >> giving work. >> >> The only thing I'm asking is, please make the ex-region CAPS giving >> for this optional, e.g. provide a region implementation to proxy it >> and allow selection of either a region caps (for trusted regions and >> closed grids) and inventory server CAPS (for open grids that have >> accessible inventory servers). >> >> Melanie >> >> >> Diva Canto wrote: >> >>> After more poking at the viewer, here's what I found. >>> >>> FetchInventoryDescendents seems to be working consistently over CAPs, in >>> fact better than over UDP. When the agent logs in, the client always >>> invokes that CAP, unlike the message over UDP which only seems to come >>> after a clear cache. That first FetchInventoryDescendents request is for >>> getting the 1st-level items just below the Root folder. Whenever you >>> unfold folders, this CAP is invoked too, and that happens all the time. >>> In other words, the inventory skeleton is passed in a lazy mode to the >>> client, and directly from wherever this Capability is being served. Why >>> is this commented in the code? >>> >>> Observation #1: we could make the provider of this CAP be the inventory >>> service, instead of the region. That way, the user can *browse* the >>> contents of her inventory *safely everywhere* -- even if the region >>> where she is doesn't have her inventory. >>> >>> Unfortunately, the goodies sort of stop here. I tried coercing the >>> viewer to use FetchInventory, CreateInventoryItem, >>> CreateInventoryFolder, and other inventory manipulation operations, over >>> CAPs, but the viewer doesn't seem to want to do that. The only ones that >>> are over CAPs are the ones we already have related to notecards and >>> scripts. Those can also be split eventually, some of them should go to >>> the inv server directly, namely: NewFileAgentInventory, >>> UpdateNotecardAgentInventory, UpdateScriptAgentInventory. There's really >>> no need to let the regions serve these. >>> >>> However, even though inventory access doesn't seem to be entirely over >>> CAPs, not all is lost. What this means is that we can stop regions (the >>> untrusted ones, at least) from getting the user's inventory in its >>> entirety while the user still *sees* it. The next problem is *access*. >>> That is, I can see I have a shape in there, but as soon as I try to wear >>> it, that fails, because the region where I am doesn't known anything >>> about it (it doesn't have the assetID, because it doesn't have the >>> inventory). >>> >>> We have three options here. >>> >>> (1) We have the region fetch that inventory item from the user's >>> inventory, and then send it to the viewer; so the region gets a copy of >>> the item. >>> (2) We have the region serve merely as front-end of the request, passing >>> it to the user's inventory server or home region, and have them send the >>> actual item to the viewer. (my favorite; in this case, Identity and >>> Authentication would be established by the viewer's EndPoint, again) >>> (3) We simply don't serve the item. >>> >>> In any case, the great thing here is that the region doesn't have the >>> complete listing of the users' inventory items, but the viewer does. >>> That is, we avoid that dreadful "Loading...". The region may get >>> requests for fetching items, and those IDs come from the client. So when >>> the inv server gets a request to fetch an item, we know that with all >>> likelihood this request came from the legitimate viewer; the odds of the >>> region guessing a valid itemID are pretty low. >>> >>> --- >>> >>> I can already hear Melanie saying that any of this is going to break 57 >>> things related to attachments and scripting :-) That's ok. I'm talking >>> about crossing boundaries of trust for now, so Hypergrid, OSGrid and >>> others like that. And there's ways of not breaking attachments and >>> scripts across region boundaries. >>> >>> My main objective is to defeat what I've put DNCH doing at the moment -- >>> wiping out people's inventories. >>> >>> Melanie wrote: >>> >>>> That is what was said. Linden reverted the inventory protocol to UDP >>>> on their servers because of an issue in the viewer that was so >>>> fundamental that it was decided to not be worth fixing. >>>> >>>> Whether this is true, I don't know. but it was said. >>>> >>>> Melanie >>>> >>>> Diva Canto wrote: >>>> >>>> >>>>> Melanie wrote: >>>>> >>>>> >>>>>> Linden turned it off because it's broken in the client. So, we can >>>>>> try to use it but will hit the same wall, since the client was never >>>>>> fixed. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> Melanie: are you 100% sure about this? This, of course, is critical. The >>>>> whole point of my thinking was to access inventory over the consistent >>>>> model of CAPs; if that's not working, then everything else is minor. >>>>> >>>>> _______________________________________________ >>>>> Opensim-dev mailing list >>>>> Opensim-dev@lists.berlios.de >>>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>>> >>>>> >>>>> >>>>> >>>> _______________________________________________ >>>> Opensim-dev mailing list >>>> Opensim-dev@lists.berlios.de >>>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>>> >>>> >>>> >>> >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Opensim-dev mailing list >>> Opensim-dev@lists.berlios.de >>> https://lists.berlios.de/mailman/listinfo/opensim-dev >>> >> _______________________________________________ >> Opensim-dev mailing list >> Opensim-dev@lists.berlios.de >> https://lists.berlios.de/mailman/listinfo/opensim-dev >> >> > > > > > ------------------------------------------------------------------------ > > _______________________________________________ > Opensim-dev mailing list > Opensim-dev@lists.berlios.de > https://lists.berlios.de/mailman/listinfo/opensim-dev _______________________________________________ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
