<br><br><b><i>liu xiaolu <lulurun@gmail.com></i></b> wrote:<blockquote class="replbq" style="border-left: 2px solid rgb(16, 16, 255); margin-left: 5px; padding-left: 5px;"> <div dir="ltr">Hi, _MW,<br><br>>a quick follow on, what I mean about it being too rigid, is that by having a set userserver set<br>>url in the inventory server.<br>I think I have to explain more about the security change.<br><br>[definition:]<br>* To put inventoryserver and userserver separatly, means they are on different servers and use<br>   different DB.<br>* "inventory information" is very *closely* related to user information(inventoryids belongs to a userid),<br>  but "inventory information" does not contain enough information that can prove user's identity.<br> * Inventoryserver holds such kind of "inventory information"<br>* Userserver holds the information that can prove user's identity(uuid/name,password) <br>[problem:]<br>* If we put inventoryserver separate from
 userserver, then inventoryserver can not claim user's<br>   identity by itself<br>  => inventoryserver has to rely on 1 or some userservers. (check_auth_session call is neccessary)<br>// Above, is the current situation<br>[solution for "too rigid":]<br>* add a new table for inventoryserver, 2 fields, useruuid, userserver_url, everytime inventoryserver<br>   extract "session_id", "user_id" from the request, get "userserver_url" by "user_id", then check the<br>  identity of "user_id" from "userserver_url" (call check_auth_session)<br><br>I really think rather than the inventory server calling a authenticate method on the user server. That the user server should send a sessionid to the inventory server when a new login happens. I guess your idea of the userserver_url was something silmilar in that the userserver would update it when a user logs in? Otherwise if it was just "hardcoded" in the db then it wouldn't solve anything.<br><br>Of course there is
 also the case of a user being online on multiple "grids" at the same time while using a single inventory server (which we have done). But if needed that shouldn't be too hard for someone to make the changes themselves. (just store mutliple sessions/grid pairs per user's inventory).<br><br> <br>>It makes it harder to use the same inventory server on multiple grids.<br>>Either for the same user (if their id on each grid was the same).<br>  >Or just multiple grids/user groups sharing a common inventory server.<br>Have you ever think about 1 grid uses multiple inventoryservers. :><br>Sounds like the opposite of what you said, but I think inventoryserver should be thought in this way:<br> *** inventoryserver is serving for the users, not the grids/regions.<br>I mean, inventory server should not be always tied up with grids, no matter 1 to n or n to 1,<br>inventory server just exists for "users", and the "users" maybe from different grids.<br><br>I really not sure
 what you mean here? Nothing I have said would stop multiple inventory servers on 1 grid. In fact I think my suggestions would make these easier to support. Also yes I'm totally talking about making a inventory server , serve users rather than "grids". Just at the moment with the security system as it is currently. It is set up for exactly the opposite. Its tying a inventory server to a grid.<br><br>I think inventory and in the future asset servers. Should be thought of a seperate services. That a user could pick whatever service they want to hold their inventory/assets and create a account on it. Then tell whatever "grid" they join/are part of to use that service. All they should need to do is set the permissions of the inventory/asset account so that the grid can access it (I also think eventally that permissions should be at the folder level, so can give a grid read only permissions or something). <br> <br>This is also a part of my plan of "interop", please refer
 to<br><a href="http://opensimulator.org/wiki/Avatar_portability_version_2">http://opensimulator.org/wiki/Avatar_portability_version_2</a><br>for more information<br> <br>regards,<br>Lulurun<br><br> </div> _______________________________________________<br>Opensim-dev mailing list<br>Opensim-dev@lists.berlios.de<br>https://lists.berlios.de/mailman/listinfo/opensim-dev<br></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>