Re: [Opensim-dev] Authentication, take 2: Capabilities
Diva Canto wrote: [...] Seriously, the right way of writing the viewer would be for it to accept capabilities for all of its functions, and default to UDP to the region if no CAP URL is set. Those 400+ messages of the Client-Server protocol should simply be handles for capability-like functions that would be implemented by assorted components, to be defined at login-time by the trusted home system. But there I go again bashing the viewer, right after my new-found love for it... grinwe should now pound on linden's door and demand MORE CAPs.../grin -- dr dirk husemann virtual worlds research ibm zurich research lab SL: dr scofield drscofi...@xyzzyxyzzy.net http://xyzzyxyzzy.net/ RL: h...@zurich.ibm.com - +41 44 724 8573 - http://www.zurich.ibm.com/~hud/ ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Authentication, take 2: Capabilities
Hehehe. And how's this for hacking in a scale of 1 to 10? Unfortunately, the viewer seems to have only a limited set of capabilities, which is a pain. For example, I wish it had a CAP for requesting teleports, so that the request would go directly to a trusted component instead of to the region where the user is. It doesn't have that CAP, as far as I can tell. However... We could use the UpdateNotecardAgentInventory CAP to send arbitrary messages directly to our trusted home system. Just edit a notecard in Inventory and write, for example `(teleport home), then save the notecard. That would go through the UpdateNotecardAgentInventory CAP directly to the inventory system, which can then parse the contents looking for messages in a bottle. Hehehe... :-) Seriously, the right way of writing the viewer would be for it to accept capabilities for all of its functions, and default to UDP to the region if no CAP URL is set. Those 400+ messages of the Client-Server protocol should simply be handles for capability-like functions that would be implemented by assorted components, to be defined at login-time by the trusted home system. But there I go again bashing the viewer, right after my new-found love for it... I'm sure we can make up for the missing CAPs in the viewer with a Web Interface, as Stefan says. Diva Canto wrote: I confess I didn't understand CAPs until they hit me in the head yesterday. I always knew the way we were using them was wrong in the sense that it defeats their purpose of being security devices. Yes, the viewer doesn't complain, but they are mute for security purposes. So, really, I'm just trying to find the right story for them in the context of this black-box viewer, and starting from basic principles. It seems that there are many ways of managing capabilities, one of them being what we are doing now. I have no idea how Linden Lab does it; but that doesn't matter. What matters is that this viewer has some buttons that we can push -- not all the buttons we would like, but some. Maybe capabilities are, indeed, a nifty idea, after one gets passed the initial this is way too complicated phase. Maybe other viewers would use them too, if we have a simple story for them. I really like their model of using secret URLs for accessing security-critical services -- that's very nice. I still don't understand this well enough to attempt the very needed comparison between capabilities and OpenID tokens. If someone already got to that point, please share! Stefan Andersson wrote: Actually, I think getting a 'true' CAPS model going (for those stacks that would use it) would be a major win. Getting more user-based stuff moved off the regions as performance and trust bottlenecks would be a major win. Regarding the user/inventory service as a bottleneck, I believe that it's no better or worse than having the region as one - walled garden or not, users will come from differing user/inventory servers anyway, and the ability to load balance those services is just as interesting as being able to load balance regions. One example is that right now, the user can get 'stuck' in an uncooperative region. As I understand it, with CAPS (if it would work) you could assure that the user at least always can teleport off an unresponsive server - even forcibly teleport him off it - which would be a major win. Along the same lines, you could start initiating some actions from a web ui, which would be a major step forward. Getting some people from the sl-dev list to cooperate closely with us to map out exactly what calls could reliably used over CAPS would be a major win. (No more guessing games - let's get the facts.) Regarding the complexity of the solution, I believe that with the current modularization that we're moving towards, and if the CAPS system could be made truly portable over region and grid modules, thru (customized) streamhandlers (there is an LLSDStreamHandler, actually) I think that the complexity could be alleviated - simply put, the trust policy would just be a matter of configuring where the trusted llsd handlers would be instantiated. If it's on a user server, or on a region server, I believe that they could use the same set of CAPS modules, if those modules had an IInventoryService, an IUserService and an ITeleportService proxy or implementation. That said, CAPS as of now is fundamentally a LLClientView thing, so one probably needs to think about how one would slice that cake. But above all, +1 on getting a 'true' CAPS implementation in place. Go Diva! (Godiva?) Best regards, Stefan Andersson Tribal Media AB Date: Thu, 26 Feb 2009 20:40:04 + From: mela...@t-data.com To: opensim-dev@lists.berlios.de Subject: Re: [Opensim-dev] Authentication, take 2: Capabilities It sounds complex, and also sounds like something that would overcomplicate scenarios where there _is_ trust. It would be great for a untrusted
Re: [Opensim-dev] Authentication, take 2: Capabilities
Sigh. I thought I'd poke at the release candidate of the viewer to see what's coming wrt CAPs. Either they changed the names of the messages, or they removed the FetchInventoryDescendents CAP altogether. Now I'm mad. ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
[Opensim-dev] Authentication, take 2: Capabilities
[Warning: long and heavy-duty stuff here] So, I just had an insight this morning as I woke up. We've scratched our heads about this fuzzy black-box component called the viewer, and how horrible it is for open systems because it assumes the regions proxy all the security-critical data etc etc. Well, the insight is that maybe this black-box component is not as bad as we think; maybe we're just not using it the right way. All our knowledge has come from poking at it with things like gridproxy and best guesses, which has taken us a long way. But none of us has seen what it actually does. I still don't know what it does, but now I'm convinced we can go a lot further with this viewer in order to make it safe in open systems. I'm hopeful, at least :-) The key: capabilities. The implications to OpenSim: enormous. First a bit of history about CAPs in OpenSim. From what I understand, CAPs in OpenSim has been a reactive process of The Lindens added X over CAPs; let's find the simplest possible thing that makes the client happy. As a result, when I first started looking at TPs etc. there was one single CAP seed per agent that was passed around throughout all the regions that the agent visited, and that was used to set up CAP URLs with virtually identical paths. The use of capabilities as security devices was completely defeated; yes, the client wasn't unhappy, it worked, but we were far away from implementing CAPs-as-secrets. Then I started fiddling with that, and changed things so that each region has its own CAPs seed per agent. However, the purpose of CAPs for security is still completely defeated, because the regions know each other's seed caps. In fact, seed caps are being generated by the departing regions for the receiving regions so that we can implement agents transfers the way we do now: eq.EnableSimulator(reg.RegionHandle, endPoint, avatar.UUID); eq.EstablishAgentCommunication(avatar.UUID, endPoint, ***capsPath***); eq.TeleportFinishEvent(reg.RegionHandle, 13, endPoint, 4, teleportFlags, ***capsPath***, avatar.UUID); The departing region that runs the code above needs to know the caps seed path of the receiving region, so it can send it to the client. Again, completely defeats the purpose of CAPs being secrets. Let's rewind. The idea behind caps is that they are opaque URLs that are a shared secret URL between the CAP giver, the CAP receiver, and the CAP-function provider. The CAP receiver is the viewer. The viewer understands (i.e. has semantics for) a number of capability-enabled functions such as the seed itself, Event Queue, NoteCard and Script updates, ... and, yes, even Inventory access! As far as we know, the semantics is defined by a mapping from pre-defined names to the CAP URLs that we send to the viewer. For example, whenever the viewer wants to update a notecard in the agent's inventory, it simply posts to the URL we gave it associated with the name UpdateNotecardAgentInventory. The viewer doesn't know what's behind that URL; that's up to (a) the capability giver to establish who the provider is and (b) to the capability provider to implement. OK, so the fundamental flaw in our thinking so far is that the *regions* are both, and always, the CAPs generators/givers and the CAP-function providers. (With one notable exception of the initial CAPs seed, which is generated by the UserLoginService for the first region). This is flawed because we can't trust the regions in general. We definitely can't have a single seed being passed around the regions, and we also can't have the departing region generate the CAPs seed for the receiving region. Furthermore, and this is even more radical, we also can't have the regions post events to the Event Queue! I'll get to this a little further down. The right way of thinking, at a high level, is this: the CAPs generator/giver must be a trusted component. We can't trust regions in general (only a few home ones), so we can't let CAPs be handled by the regions in general -- period. In an open grid system we can only trust the User server, and the servers that it trusts such as the home region and the user's inventory server. Hence the user server is the only component that should ever give out CAPs URLs (or delegate that function to a trusted component). *Implications* The implications for how we do things are enormous. For example, teleports. The right way of doing TPs safely should be to have the user/presence/homeregion server do them, not the regions. Something like this: - client requests TP on the untrusted region A to untrusted region B - untrusted region A may do whatever it wants with that request, but let's start by the base case: it complies with the request - region A notifies *the user server* that the agent wants to TP to region B - User server posts EnableSimulator for B on *a trusted* Event Queue - User server posts EnableChildAgent for B on that queue, with a CAP seed *pointing
Re: [Opensim-dev] Authentication, take 2: Capabilities
Justin Clark-Casey wrote: Another critical example: inventory. The CAP URL for this should be pointing directly to the Inventory server, not to the regions. I understand that inventory over CAPs had some issues in the past. I just fiddled with it this morning, and it's working -- I'm sure there are problems that I'm not seeing here on my standalone, but the basics seem to be there. That is, I gave it this: m_capsHandlers[FetchInventoryDescendents] = new RestStreamHandler(POST, capsBase + m_fetchInventoryPath, FetchInventoryRequest2); and the viewer compliantly posted to this URL when I accessed my inventory, instead of using UDP. So there's something here waiting to be used. Interesting. I can't remember if the last time this was switched on the whole thing wasn't working or whether just some particular aspect of it was broken. I suspect it was the latter. 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 ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev
Re: [Opensim-dev] Authentication, take 2: Capabilities
Here's the thing: the CAPs giver can define whatever it wants as CAPs providers. So I think what we have currently is a subset of what I'm saying below. Specifically, the CAPs giver can delegate CAPs to trusted regions. But obviously, we need to think more about this. My main goal here is to flip the tables and see what under. Melanie wrote: It sounds complex, and also sounds like something that would overcomplicate scenarios where there _is_ trust. It would be great for a untrusted grid scenario, but how would a trusted grid scenario (e.g. walled garden) be built to be more efficient and less bottlenecky? This setup creates a SPF for every user. Not good. Becoming disabled/unresponsive because the user server or home region fails? that is more brittle than LL! Melanie Diva Canto wrote: [Warning: long and heavy-duty stuff here] So, I just had an insight this morning as I woke up. We've scratched our heads about this fuzzy black-box component called the viewer, and how horrible it is for open systems because it assumes the regions proxy all the security-critical data etc etc. Well, the insight is that maybe this black-box component is not as bad as we think; maybe we're just not using it the right way. All our knowledge has come from poking at it with things like gridproxy and best guesses, which has taken us a long way. But none of us has seen what it actually does. I still don't know what it does, but now I'm convinced we can go a lot further with this viewer in order to make it safe in open systems. I'm hopeful, at least :-) The key: capabilities. The implications to OpenSim: enormous. First a bit of history about CAPs in OpenSim. From what I understand, CAPs in OpenSim has been a reactive process of The Lindens added X over CAPs; let's find the simplest possible thing that makes the client happy. As a result, when I first started looking at TPs etc. there was one single CAP seed per agent that was passed around throughout all the regions that the agent visited, and that was used to set up CAP URLs with virtually identical paths. The use of capabilities as security devices was completely defeated; yes, the client wasn't unhappy, it worked, but we were far away from implementing CAPs-as-secrets. Then I started fiddling with that, and changed things so that each region has its own CAPs seed per agent. However, the purpose of CAPs for security is still completely defeated, because the regions know each other's seed caps. In fact, seed caps are being generated by the departing regions for the receiving regions so that we can implement agents transfers the way we do now: eq.EnableSimulator(reg.RegionHandle, endPoint, avatar.UUID); eq.EstablishAgentCommunication(avatar.UUID, endPoint, ***capsPath***); eq.TeleportFinishEvent(reg.RegionHandle, 13, endPoint, 4, teleportFlags, ***capsPath***, avatar.UUID); The departing region that runs the code above needs to know the caps seed path of the receiving region, so it can send it to the client. Again, completely defeats the purpose of CAPs being secrets. Let's rewind. The idea behind caps is that they are opaque URLs that are a shared secret URL between the CAP giver, the CAP receiver, and the CAP-function provider. The CAP receiver is the viewer. The viewer understands (i.e. has semantics for) a number of capability-enabled functions such as the seed itself, Event Queue, NoteCard and Script updates, ... and, yes, even Inventory access! As far as we know, the semantics is defined by a mapping from pre-defined names to the CAP URLs that we send to the viewer. For example, whenever the viewer wants to update a notecard in the agent's inventory, it simply posts to the URL we gave it associated with the name UpdateNotecardAgentInventory. The viewer doesn't know what's behind that URL; that's up to (a) the capability giver to establish who the provider is and (b) to the capability provider to implement. OK, so the fundamental flaw in our thinking so far is that the *regions* are both, and always, the CAPs generators/givers and the CAP-function providers. (With one notable exception of the initial CAPs seed, which is generated by the UserLoginService for the first region). This is flawed because we can't trust the regions in general. We definitely can't have a single seed being passed around the regions, and we also can't have the departing region generate the CAPs seed for the receiving region. Furthermore, and this is even more radical, we also can't have the regions post events to the Event Queue! I'll get to this a little further down. The right way of thinking, at a high level, is this: the CAPs generator/giver must be a trusted component. We can't trust regions in general (only a few home ones), so we can't let CAPs be handled by the regions in general -- period. In an open grid system we can only trust the User server, and the servers that it trusts such as the home region
Re: [Opensim-dev] Authentication, take 2: Capabilities
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
Re: [Opensim-dev] Authentication, take 2: Capabilities
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
Re: [Opensim-dev] Authentication, take 2: Capabilities
I don't subscribe to that mailing list. Can someone please do that? I've been searching on Google, and I found a meeting with Mark where he clearly says that inventory access has swicthed to caps: http://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/2008_Mar_13 (search 'caps') I couldn't find documents mentioning the retraction of that yet. Dirk Krause wrote: Maybe it would make sense to verify this on sl-dev mailing list? -Ursprüngliche Nachricht- Von: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Melanie Gesendet: Donnerstag, 26. Februar 2009 22:10 An: opensim-dev@lists.berlios.de Betreff: Re: [Opensim-dev] Authentication, take 2: Capabilities 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
Re: [Opensim-dev] Authentication, take 2: Capabilities
I can do that. Is the correct question: Are the inventory requests done via caps or via UDP? Von: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Diva Canto Gesendet: Donnerstag, 26. Februar 2009 22:24 An: opensim-dev@lists.berlios.de Betreff: Re: [Opensim-dev] Authentication, take 2: Capabilities I don't subscribe to that mailing list. Can someone please do that? I've been searching on Google, and I found a meeting with Mark where he clearly says that inventory access has swicthed to caps: http://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/2008_Mar_13 (search 'caps') I couldn't find documents mentioning the retraction of that yet. Dirk Krause wrote: Maybe it would make sense to verify this on sl-dev mailing list? -Ursprüngliche Nachricht- Von: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Melanie Gesendet: Donnerstag, 26. Februar 2009 22:10 An: opensim-dev@lists.berlios.de Betreff: Re: [Opensim-dev] Authentication, take 2: Capabilities 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
Re: [Opensim-dev] Authentication, take 2: Capabilities
Yes, something like that. And If they're done via UDP, what was the problem with the Inventory CAP that was deployed sometime last year? Thanks. Dirk Krause wrote: I can do that. Is the correct question: Are the inventory requests done via caps or via UDP? *Von:* opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] *Im Auftrag von *Diva Canto *Gesendet:* Donnerstag, 26. Februar 2009 22:24 *An:* opensim-dev@lists.berlios.de *Betreff:* Re: [Opensim-dev] Authentication, take 2: Capabilities I don't subscribe to that mailing list. Can someone please do that? I've been searching on Google, and I found a meeting with Mark where he clearly says that inventory access has swicthed to caps: http://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/2008_Mar_13 (search 'caps') I couldn't find documents mentioning the retraction of that yet. Dirk Krause wrote: Maybe it would make sense to verify this on sl-dev mailing list? -Ursprüngliche Nachricht- Von: opensim-dev-boun...@lists.berlios.de mailto:opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Melanie Gesendet: Donnerstag, 26. Februar 2009 22:10 An: opensim-dev@lists.berlios.de mailto:opensim-dev@lists.berlios.de Betreff: Re: [Opensim-dev] Authentication, take 2: Capabilities 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 mailto:Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de mailto:Opensim-dev@lists.berlios.de https://lists.berlios.de/mailman/listinfo/opensim-dev ___ Opensim-dev mailing list Opensim-dev@lists.berlios.de mailto: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
Re: [Opensim-dev] Authentication, take 2: Capabilities
Done. Von: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Diva Canto Gesendet: Donnerstag, 26. Februar 2009 22:32 An: opensim-dev@lists.berlios.de Betreff: Re: [Opensim-dev] Authentication, take 2: Capabilities Yes, something like that. And If they're done via UDP, what was the problem with the Inventory CAP that was deployed sometime last year? Thanks. Dirk Krause wrote: I can do that. Is the correct question: Are the inventory requests done via caps or via UDP? Von: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Diva Canto Gesendet: Donnerstag, 26. Februar 2009 22:24 An: opensim-dev@lists.berlios.de Betreff: Re: [Opensim-dev] Authentication, take 2: Capabilities I don't subscribe to that mailing list. Can someone please do that? I've been searching on Google, and I found a meeting with Mark where he clearly says that inventory access has swicthed to caps: http://wiki.secondlife.com/wiki/User:Zero_Linden/Office_Hours/2008_Mar_13 (search 'caps') I couldn't find documents mentioning the retraction of that yet. Dirk Krause wrote: Maybe it would make sense to verify this on sl-dev mailing list? -Ursprüngliche Nachricht- Von: opensim-dev-boun...@lists.berlios.de [mailto:opensim-dev-boun...@lists.berlios.de] Im Auftrag von Melanie Gesendet: Donnerstag, 26. Februar 2009 22:10 An: opensim-dev@lists.berlios.de Betreff: Re: [Opensim-dev] Authentication, take 2: Capabilities 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
Re: [Opensim-dev] Authentication, take 2: Capabilities
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
Re: [Opensim-dev] Authentication, take 2: Capabilities
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
