+1 on a proper document being made and posted on this list. The whole problem comes from the fact that wasn't done before the changes were made to svn.<br><br>My purpose hasn't really been to find the finial solution, but just to show that there is a problem that needs dealing with.<br><br><b><i>Justin Clark-Casey <jjustincc@googlemail.com></i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> Michael Wright wrote:<br>> Sorry one more email,<br>> <br>> Just noticed your latest reply on <br>> http://opensimulator.org/mantis/view.php?id=1828. And your suggestion on <br>> there, seems a good step forward. Can see some weakness in the public <br>> key scheme. But it at least shouldn't break anything.<br>> <br>> I guess a lot of the problems do come from the language barrier, as that <br>> suggestion is very similar to one approach I have been suggesting in <br>> this
thread. Which you kept rejecting.<br><br>As I've suggested in http://opensimulator.org/mantis/view.php?id=1828, I <br>think this is one of those things that really needs a proper spec <br>formulated before implementation. A security infrastructure (as we've <br>already seen) affects a lot of things and can impact many use cases. <br>Also, if we're going to do this it needs to have many eyes on it so we <br>don't go with something that has holes that will be difficult to put <br>right later.<br><br>It's very difficult to determine the arguments via multiple stream of <br>consciousness e-mails, especially if they're not written in a <br>developer's first language. This isn't meant as an insult but merely as <br>a statement of fact.<br><br>> <br>> */Michael Wright <michaelwri22@yahoo.co.uk>/* wrote:<br>> <br>> <br>> <br>> */liu xiaolu <lulurun@gmail.com>/* wrote:<br>> <br>> These my final points:<br>> 1. Objectively, once more,
inventoryserver contains no<br>> information that can make sure if a request<br>> is or not from a valid user. only userserver contains that<br>> information, and we all do not want<br>> such kind of "identity" information to be copied everywhere.<br>> 2. according to 1, no matter push or pull, inventoryserver has<br>> to validate the request or anyone can<br>> use it. => inventoryserver has to "pull" or be "pushed"<br>> authed information from 1 or many<br>> userservers.<br>> 3. that doesn't mean inventoryserver has to rely on some<br>> userservers, inventoryserver just rely on<br>> if the user want it to validate and how the user want it to<br>> validate requests. as I said,<br>> inventoryserver exists for its user, not userserver, why<br>> inventoryserver have to "pull" or be<br>>
"pushed" something is because "users" *want* do that to save<br>> their inventory. inventoryserver<br>> works for users, it does not always trust 1 or some<br>> userservers, it trusts what the user specified.<br>> It acts as what the user want it to do.<br>> <br>> Your approach isn't creating inventory for users. Its creating<br>> inventory for a single grid and the users on that grid.<br>> <br>> <br>> Y. "push" has security issue that any remote peer can "push" to<br>> inventoryserver. to set access<br>> permissions on inventoryserver side or make a "safe peers"<br>> list ?<br>> I think the "permission" should not be "user" based, because<br>> it is unsafe either, then if the<br>> "permission" is "url" based, doesn't that mean the same as<br>> inventoryserver rely on the<br>>
"safe peers" ?<br>> <br>> Again if you have a authentication scheme in place so that only<br>> "trusted" user servers could push the sessionID. Then its no<br>> different.<br>> <br>> Currently the user server can do things like create new<br>> inventory set and request all the folders for a user. And the<br>> only security is checking that the reported ip address in the<br>> request matches the one stored for the user server.<br>> <br>> But having said that, if we could at least get a pull system<br>> that works and doesn't break use cases then thats great. But<br>> at the moment the current system does break perfectly valid<br>> use cases.<br>> <br>> Really, I think "push" is much more dangerous, and "pull" does<br>> not have to be designed "rigid".<br>> if you can take time to write
some of the usecases that should<br>> be support, but current "pull"<br>> inventory breaks them, I would like to do what ever I can do to<br>> think and implement.<br>> <br>> I just don't understand why you haven't read anything I have<br>> said or if you have read it. Decided to ignore it.<br>> <br>> I have repeatedly descriped valid use cases that we should support.<br>> <br>> <br>> <br>> <br>> */liu xiaolu <lulurun@gmail.com><br>> <mailto:lulurun@gmail.com>>/* wrote:<br>> <br>> After all, please understand that I am not "selling" how<br>> my "secure inventory" is great,<br>> I made it because I found my interop module is an<br>> ease-to-use tool to modify others' inventory(at OSGrid.org).<br>> if there are bugs or broken things please let me
know.<br>> hope it is fixed or I would like to offer what I can do<br>> to help the fix.<br>> What I am trying to do is to share my point of view on<br>> "interop", that is what I called avatar portability.<br>> maybe I replied to a wrong mail.<br>> <br>> So, about the usecase: (I finanlly got your idea, from<br>> the quoted mail)<br>> >The use case (or one of many) that I'm talking about,<br>> is if a user has inventory on a inventory server, that<br>> user's inventory shouldn't be tied to any user<br>> server/grid. So the user should be able to use the same<br>> inventory set on multiple grids. At the<br>> >moment that means they have the same userid on each<br>> grid but thats no problem (and in
the future I hope we<br>> will support a better way of identifying a inventory<br>> belongs to a user).<br>> ><br>> >So lets call the Inventory server InvN like you used.<br>> My single inventory set (of folders/items) on that<br>> server is called InvSetA. Then we have Grid A and Grid<br>> B. With user server A and B. When I log into grid A it<br>> should use InvN to receive InvSetA.<br>> >But also if I log out of grid A and log into grid B<br>> then it should also use InvN to receive InvSetA. The<br>> inventory set (of folders/items) isn't tied to a single<br>> grid/avatar. It belongs to the user. The "grid" is just<br>> using a guid (avatarID) to access the correct<br>> >inventory set. So as
long as both grids use the same<br>> id, they should be able to use the same inventory.<br>> When I read the above sentences, what I was thinking is<br>> "why it is required to be like such a case?"<br>> Still, There are 3 situations I can imagine:<br>> *1*. UserA and UserB do not know each other, by (small)<br>> chance, thier UUID are the same.<br>> uuid collision, hard to say anything.<br>> yes, we do should care about this, though I<br>> learned that uuid wouldnot duplicate in common life, but<br>> we cannot trust the implementations.<br>> I think this is possibly not what you mean, even<br>> if you really mean this ...<br>> the "userserver_dictionary" should be<br>>
"uuid@grid_identifier", "userserver_url",<br>> grid_identifier can be the address(host,ip) of the grid<br>> service, hmmm ...<br>> *2*. UserA and UserB are the same person.<br>> In order to login to both GridA and GridB, an User<br>> copied his/her account both at GridA(UserA) and<br>> GridB(UserB), so they are having the same uuid.<br>> I suggest to use the way I mentioned: he/she can<br>> always keep one account at GridA, and travel to both<br>> GridA and GridB.<br>> reasons for the suggestion:<br>> 1. coping account is not a forever solution for<br>> grid-grid travel.<br>> 2. there is an advanced way, we should encourage<br>> ourself to use that<br>> *3*. UserA
and UserB are completly different accounts,<br>> they are friends/groupmember(or they are owned by the<br>> same person who intend to do such thing),<br>> they want to share InvSetA(both of them can CRUD<br>> InvSetA)<br>> InvSetA only can be specified by user uuid, so<br>> they *have* to have the same uuid to share InvSetA,<br>> this can be solved in another level - inventory<br>> does not belongs to a user, it belongs to a group.<br>> * a group has 1 uuid used to identify inventory<br>> * a group contains mutilple/single user<br>> this may introduce "join" SQL statements to<br>> "select" the inventory, instead of just "select" by<br>> "uuid". ... no deeper thoughts.<br>> <br>>
I want it be a "pulling" system, because<br>> * "push" has security issues, session_id or what ever<br>> things that is used as a secret to prove identity,<br>> shouldn't be "pushed" to everywhere<br>> * I still do not think the case you are concerning is a<br>> major case, or even I think it is strange, except you<br>> are meaning *3*. but *3* is another issue.<br>> * "pulling" reduces the responsibility of<br>> inventoryserver, in the case, inventoryserver couldn't<br>> get auth infomation for the specified userserver,<br>> because userserver<br>> is specified by user itself, so it the problem of the<br>> user, not the inventory, but "push" is the opposite, to<br>> think inventory/asset server will play a important
roll<br>> in the future, the less responssibility it has the<br>> more it is reliable.<br>> <br>> Wrote too much english today ... see you tomorrow<br>> thank you for your detailed explanations.<br>> <br>> regards,<br>> lulurun<br>> <br>> 2008/7/26 Michael Wright <michaelwri22@yahoo.co.uk><br>> <mailto:michaelwri22@yahoo.co.uk>>:<br>> <br>> I might be missing something but I don't see how<br>> this solution addresses some of the problems. Maybe<br>> I wasn't very clear on some of the use cases that<br>> would currently be broke.<br>> <br>> The use case (or one of many) that I'm talking<br>> about, is if a user has inventory on a inventory<br>>
server, that user's inventory shouldn't be tied to<br>> any user server/grid. So the user should be able to<br>> use the same inventory set on multiple grids. At the<br>> moment that means they have the same userid on each<br>> grid but thats no problem (and in the future I hope<br>> we will support a better way of identifying a<br>> inventory belongs to a user).<br>> <br>> So lets call the Inventory server InvN like you<br>> used. My single inventory set (of folders/items) on<br>> that server is called InvSetA. Then we have Grid A<br>> and Grid B. With user server A and B. When I log<br>> into grid A it should use InvN to receive InvSetA.<br>> But also if I log out of grid A and log into grid
B<br>> then it should also use InvN to receive InvSetA. The<br>> inventory set (of folders/items) isn't tied to a<br>> single grid/avatar. It belongs to the user. The<br>> "grid" is just using a guid (avatarID) to access the<br>> correct inventory set. So as long as both grids use<br>> the same id, they should be able to use the same<br>> inventory.<br>> <br>> So in this case if we have the pull from user server<br>> approach to authenticating then it needs to switch<br>> between user server A and B, depending on what grid<br>> the user is currently logged into. So again it would<br>> require a push somewhere to update which is the<br>> current user server for that
user.<br>> <br>> As far as I can tell, your solution just stops a<br>> inventory server being tied to a single grid/user<br>> server and instead ties each inventory set to a<br>> grid/user server. That is better than tying the<br>> whole server. But it doesn't support the above case.<br>> <br>> There are a number of other use cases that would<br>> require multiple grids/instances to access a single<br>> inventory set.<br>> <br>> I find it helps if we think of User server and the<br>> grid server as seperate to the inventory and asset<br>> server. The user server defines what users can<br>> access a grid (plus other data like what inventory<br>> server that user is
using). The grid server defines<br>> and manages what regions are on a grid.<br>> <br>> But asset and inventory server can (in part) be<br>> thought of more as end user servers. In that a user<br>> could use the same servers on multiple grids and<br>> that can mean using the same inventory on all grids.<br>> So then if we think about defining on the asset and<br>> inventory servers what grids/regions can access them.<br>> <br>> <br>> <br>> */liu xiaolu <lulurun@gmail.com><br>> <mailto:lulurun@gmail.com>>/* wrote:<br>> <br>> First, I want to clarify that, I am not against<br>> what you said<br>> To release inventory, asset server become<br>>
independent ones is also what I have been<br>> working on.<br>> <br>> I am just trying to introduce my thoughts:<br>> >>[solution:]<br>> >>* add a new table for inventoryserver, 2<br>> fields, useruuid, userserver_url, everytime<br>> inventoryserver<br>> >> extract "session_id", "user_id" from the<br>> request, get "userserver_url" by "user_id", then<br>> check the<br>> >> identity of "user_id" from "userserver_url"<br>> (call check_auth_session)<br>> >I really think rather than the inventory<br>> server calling a authenticate method on the user<br>> server.
That<br>> >the user server should send a sessionid to the<br>> inventory server when a new login happens. I guess<br>> >your idea of the userserver_url was something<br>> silmilar in that the userserver would update it when<br>> >a user logs in? Otherwise if it was just<br>> "hardcoded" in the db then it wouldn't solve<br>> anything.<br>> <br>> sorry for the lack of explanation of the new<br>> table, temporary let me call it<br>> "userserver_dictionary".<br>> * "userserver_dictionary" is a table always<br>> together with inventoryfolers, inventoryitems<br>> * "userserver_dictionary" has 2 column: user_id<br>>
pkey, userserver_url<br>> // user registration<br>> when a new user registered at a GridService G1,<br>> the user will possibly have its account on G1's<br>> userserver U1, then, no matter which<br>> inventoryserver the user is using(or going to<br>> use), assume it is called InvN,<br>> InvN's "userserver_dictionary" would be added 1<br>> record <"uid", U1's url>,<br>> // user login to VW<br>> * user get authentication at U1, get "session_id"<br>> * user login into a regionserver, regionserver<br>> gets user's profile and extract user's<br>> inventoryserver InvN from its profile.<br>>
* regionserver requests<br>> getInventory("session_id", user.uuid) from InvN.<br>> * InvN gets "U1's url" by user.uuid from<br>> "userserver_dictionary"<br>> * InvN requests check_auth_session("session_id",<br>> user.uuid) from "U1's url"<br>> //<br>> in this case, dose InvN satisfies what you want ?<br>> * InvN is separate from any other server<br>> * InvN is independent, not rely on any<br>> userserver, it pull identity under user's<br>> specification(get "userserver_url" by uuid)<br>> * InvN can store users from different gridsevices<br>> <br>> -- <br>> Lulurun<br>>
_______________________________________________<br>> Opensim-dev mailing list<br>> Opensim-dev@lists.berlios.de<br>> <mailto:Opensim-dev@lists.berlios.de><br>> https://lists.berlios.de/mailman/listinfo/opensim-dev<br>> <br>> <br>> ------------------------------------------------------------------------<br>> Not happy with your email address?<br>> Get the one you really want<br>> <http: uk.docs.yahoo.com="" ymail="" new.html=""> - millions<br>> of new email addresses available now at Yahoo!<br>> <http: uk.docs.yahoo.com="" ymail="" new.html=""><br>> <br>> _______________________________________________<br>> Opensim-dev mailing list<br>>
Opensim-dev@lists.berlios.de<br>> <mailto:Opensim-dev@lists.berlios.de><br>> https://lists.berlios.de/mailman/listinfo/opensim-dev<br>> <br>> <br>> <br>> <br>> -- <br>> Lulurun<br>> _______________________________________________<br>> Opensim-dev mailing list<br>> Opensim-dev@lists.berlios.de<br>> <mailto:Opensim-dev@lists.berlios.de><br>> https://lists.berlios.de/mailman/listinfo/opensim-dev<br>> <br>> <br>> ------------------------------------------------------------------------<br>> Not happy with your email address?<br>> Get the one you really want<br>> <http: uk.docs.yahoo.com="" ymail="" new.html=""> - millions of new<br>> email addresses available now at Yahoo!<br>> <http:
uk.docs.yahoo.com="" ymail="" new.html=""><br>> <br>> _______________________________________________<br>> Opensim-dev mailing list<br>> Opensim-dev@lists.berlios.de<br>> <mailto:Opensim-dev@lists.berlios.de><br>> https://lists.berlios.de/mailman/listinfo/opensim-dev<br>> <br>> <br>> <br>> <br><br>=== message truncated ===</mailto:Opensim-dev@lists.berlios.de></http:></http:></mailto:Opensim-dev@lists.berlios.de></mailto:Opensim-dev@lists.berlios.de></http:></http:></mailto:Opensim-dev@lists.berlios.de></mailto:lulurun@gmail.com></lulurun@gmail.com></mailto:michaelwri22@yahoo.co.uk></michaelwri22@yahoo.co.uk></mailto:lulurun@gmail.com></lulurun@gmail.com></lulurun@gmail.com></michaelwri22@yahoo.co.uk></blockquote><br><p>
<hr size=1>
Not happy with your email address?
<br> <a href="http://uk.docs.yahoo.com/ymail/new.html"> Get the one you
really want</a> - millions of new email addresses available now at <a
href="http://uk.docs.yahoo.com/ymail/new.html"> Yahoo!</a>