On Jul 1, 2011, at 3:34 PM, Jonne Nauha wrote: > Toni will you be adding the client connection also as a parameter for the > signals? I think many permission things want to check per user
That's what I did yesterday, as mentioned here and shown in the example handler: > On Fri, Jul 1, 2011 at 10:17 AM, Toni Alatalo <t...@playsign.net> wrote: > Completed the first step yesterday actually, the signal now has the user > connection as a parameter so you can treat different users differently. void Scene::SceneManager::AboutToModifyEntity ( ChangeRequest * req, UserConnection * user, Scene::Entity * entity ) The user connection had the connection id, login data, and arbitrary properties that your authentication handler can add. For example the access rights level or group name or something if you use such. UserConnection is documented in http://www.realxtend.org/doxygen/class_user_connection.html > I think the reference implementation could be something like this: Check all > connections, allow everyone access, but check a server wide password and if > its sent by the client, push that client connection id to a list. Only IDs in > this list can delete entities/components. So everyone gets in but "admins" > who know this server password and set it on login have higher rights. Yah this is what I meant with a simple / example master password impl too. Instead of a list of authorized connections, it could be just put as a UserConnection property in the server side authentication code, so no bookkeeping of the connections wouldn't be needed and the property is easy to check in the AboutToModify handler. Indeed that could be a simple thing we provide in the standard distro. Just put a master pwd in a .ini, via some nice preferences UI perhaps, like you suggested in another post. And editing is enabled only when this pwd is given. I was actually thinking it could be some 'request god rights' button in the GUI, like in slviewer, so one can get the rights also after login. BTW regarding that other post: the password (hash) can be securely just in the code in JS too -- the perm hook JS file doesn't need to be an asset on the web, it is for server only, it doesn't need to be referred by any scene entity that the client gets. The current deny-all script you can use just by starting the server with --run /path/to/my/permissioncheck.js, or copying it to the jsmodules/startup/ folder on the server. Or if you want to put it as EC_Script in an entity for some reason, you can make that entity local only so clients don't see it. One reason why I was thinking that a shared client-server permissionscheck entity might be nice, though, would be to give GUI notifications when editing is prevented: the script on the server side could send entity actions to the client side to show a message when it rejects some change etc. > in Tundra making this token exchange thing will be trivial to make, it will > probably have to be a c++ module that the security script asks things from. > It would be nice if we could make simple http server/handler directly into > the js running on the server, im not sure if that is possible, probably is > with some external js lib at least :) The login portal and the server thing > need some common secret to hash things or something similar, so just anyone > cant call the http handler with fake data and get approval to login with > their self made token. I don't see a need for c++ in any of this, but sure is possible to write in that too. Python stdlib xmlrpc is nice for querying external web services, that's what the simian grid auth connector in Tundra uses. With Javascript / QtScript you can use qt's network api for http. For per-entity ownership etc., have been thinking that using a DynamicComponent to store the data (e.g. the openid url of the owner, or the SimianGrid or MOODLE user id, or the group name or whatever) works nicely .. as it's just data anyway. The permissions handling py/js module can add that to all (applicable) entities and prepopulate it with the default values, so it shows with the right fields in the GUI. Thanks for the thoughts, > Jonne Nauha ~Toni > > So that is already in and coming to next release. Would be great if you > could start using it straight away, if you can build your own > development version. > > > If not, could accounts/permissions be added to Tundra by creating > > our own simple Python module? How complicated? External > > authentication looks fairly direct. > > We've continued with that same design: the core has qt signals as hooks > that 3rd party c++/py/js code can use to implement accounts/permissions > how it wants. > > This is how I've tested it while developing, a js func that denies all > remote editing: > https://github.com/realXtend/naali/blob/tundra/bin/jsmodules/apitest/permissioncheck.js > > s.AboutToModifyEntity.connect(function(change, user, entity) { > print("Denying change by user: " + user + " on entity: " + entity); > change.Deny(); > }); > > The post with the complete spec apparently accidentally went to a thread > that has other things earlier, is in > http://groups.google.com/group/realxtend-dev/browse_thread/thread/79d97c6cbfbac801 > in the post titled 'permissions' dated Jun 23 9:52am (for me at least) > > Will put that to a doxygen page so it'll show in > http://www.realxtend.org/doxygen/ > > The plan there is to add fine grained signals for allowing/rejecting not > only any editing of an entity, but being able to e.g. allow adding > certain components but not others, or touching certain attributes in > some component but not others .. or allow certain attribute value ranges > only etc. But that is not implemented yet. I've been right now actually > wondering about the urgency of that, 'cause for some use cases the > already implemented overall entity editing signal suffices. I can > probably implement all those on the 2nd week of July if necessary, > otherwise in August after holiday. So getting feedback on the needs > within a week would be great. > > We also talked with Jukka about some sort of a reference implementation > that'd give the basics out of the box, am not sure how that would look > like. Earlier successfully tested authentication against simiangrid, > dunno if it has something that'd be nice with permissions, am curious > about other generic user servers out there (and know that some probably > want to use MOODLE for groups and permissions and such - integrating > that in e.g. py should be simple) > > ~Toni > > -- > http://groups.google.com/group/realxtend > http://www.realxtend.org > > > -- > http://groups.google.com/group/realxtend > http://www.realxtend.org -- http://groups.google.com/group/realxtend http://www.realxtend.org
