Users Sync Suggestion and doubts

Hello,

I has been following close the development of this great joomla extension, im still on a 0.6, but soon we will be migrating to 0.7 and im really willling to test and use com_opensim. Tho i have some doubts and suggestion about the users for a big user database. So far we can assing a opensim user to a joomla user, thats cool, but what if the opensim users base is over 4000 users?? and you use joomla as the front page for the opensim grid with just a few users for forum etc?

I believe the most reliable way to handle this, would be to import opensim users into joomla and keep them on sync kind of bridged. Looking at it from the practical way, assing manually or even create a joomla user for a set of users on a big opensim user base manually can be a hard work and can lead to mistakes, now if the opensim user base can be imported into the joomla user base and keep it on sync would be a smooth implementation, keeping the same features that com_opensim already have, so the opensim user can create \"alts\" under his main opensim/joomla account and gaining the advatanges of everthig that joomla can offer as cms.


Just an Idea.
Regards
Aramil

Hi aramil

Thanks for your thoughts. I have been looking on that already since I thought, this question might come up one day <img src=\"{SMILIES_PATH}/icon_e_wink.gif\" alt=\"\" title=\"Wink\" />

Unfortunately, the authentication way of OpenSim is completely different to Joomla ... or better to say: the way, the password is stored. While Joomla is storing the password \"just\" md5 encrypted (which is secure enough in my opinion), OpenSim uses an additional SALT (an internal string) to encrypt the password.

As the component has access to the salt string, it would be easy to further encrypt Joomla accounts and bring them to OpenSim ... but it is rather impossible the other way. At least I have not figured out any way to \"decrypt\" OpenSim encrypted passwords back to \"normal\" md5 encrypted ones.

The only possibility I see is that I could add sorta \"plugin\" to the component, that changes the Joomla authentification to the same way like OpenSim, what would also give the possibility to create the Joomla account and the OpenSim account in the same process (It\'s still in question if this is a good step, but I will have a look at that maybe later just for curiousity). The other question that\'s left is: what will a change of Joomlas way of authentication interfear maybe with other components?

Greetz
FoTo50

Hello Foto50,

You are right, maybe it will mess with the other components, we was thinking tho... what if... sort some plugin, that import the os user into joomla user table (i guess only first name, email, pass) with a generic and impossible to guess pass, so they have to retrive the pass from joomla? that way they will have a new pass under joomla (of course is a extra step but easy i think), then the relation between the os account and the joomla account can be done manually, so far the pass is the only thing that is bothering. What you think?

Question: It work with 0.7.x on grid mode?

regard

WB aramil <img src=\"{SMILIES_PATH}/icon_e_smile.gif\" alt=\"\" title=\"Smile\" />

I saw that u have been inworld on FoToGrid and I just missed you by maybe 1/2 hour ... what a pity!

I recently got an interesting idea from \"Paul Preibisch\" for an approach to this problem (actually it was rjspence sending me his idea): The basic is to have a sort of \"terminal\" inworld that communicate with the component.

So if you have an inworld account already and want to benefit of the components advantages on the website side:

• If the user hasnt done so yet, create a regular joomla account
• instead of creating the inworld account could be a button like \"get identify key\" that gives you a unique key maybe also with some slurl links to inworld teminals
• join inworld and go to the near of one of those terminals and type your key (and maybe for security also your joomla password)
• the script inside the terminal will communicate with the component and that will know from now on that this OpenSim account belongs to that Joomla account - sort of an automated \"Joomla < OpenSim\" like there is already in jOpenSim\'s User backend admin

Of course this \"terminal\" must be provided as freebie in FoToGrid enabled to save as xml and/or just as LSL script coming with the component somewhere (like the current profile module) with a good turtorial or so.

Giving the user a possibility to connect an existing OpenSim account but also taking away the manual work from the grid managers - just some initial setup needs to be done - seems to me an interesting solution. What you think?

Greetz
FoTo50

Hello once again

As of thinking of this and curious how that could work, I created it experimentally on my grid for testing already <img src=\"{SMILIES_PATH}/icon_e_biggrin.gif\" alt=\"\" title=\"Very Happy\" /> and invite you for a test <img src=\"{SMILIES_PATH}/icon_lol.gif\" alt=\"\" title=\"Laughing\" />

To be able to test it, I removed your \"Joomla < OpenSim\" relation. I did NOT delete your inworld account or your Joomla account. So if you login at <a class=\"postlink\" href=\"http://www.foto50.com\"> www.foto50.com with your joomla userdata and click on \"Your OpenSim Account\" you should again see the form to create an inworld account and [NEW] an additional link below to \"Identify Inworld\".

Clicking on that \"Identify\" link, it will provide you with some identification code as well as showing a list of available terminals where you can identify (I rezzed 2 terminals quite hidden <img src=\"{SMILIES_PATH}/icon_e_wink.gif\" alt=\"\" title=\"Wink\" /> to see if the surl\'s work correct, hehe).

When you\'re in the chat range of such a terminal inworld and type the code provided at the website, the terminal should answer you (hopefully) \"jOpenSim successfully identified your inworld account\", or - if the code was wrong: \"jOpenSim failed to identify your inworld account\", or - if jOpenSim already knows, who you are: \"Your inworld account is already identified by jOpenSim\".

With \"jOpenSim successfully identified your inworld account\", everything should again work as usual for you on the website <img src=\"{SMILIES_PATH}/icon_e_smile.gif\" alt=\"\" title=\"Smile\" />

The script of the terminals is quite easy to maintain. You need to change the targetUrl to your com_opensim (and optionally the listen channel and some terminal description) on top of the inworld script and save it. The terminal will then automatically register with jOpenSim to be listed in that terminal list. Also region and surl will be saved automatically by jOpenSim.

It would be ideal if the listen channel in the terminal script and the settings of jOpenSim would match to provide users with the correct identification code. Otherwise the users will have to guess what channel the terminal is listening on ... <img src=\"{SMILIES_PATH}/icon_lol.gif\" alt=\"\" title=\"Laughing\" />

Greetz
FoTo50

Hey that worked pretty smooth and nice! Good work! In this scenario, the OS user that didnt create previously a joomla account just need to create it link it himself in world... that was a practical idea, congrats. I think thats a clean and easy solution. When you will release that version? Ill jump on it as soon as you do <img src=\"{SMILIES_PATH}/icon_e_wink.gif\" alt=\"\" title=\"Wink\" /> .. Ahh btw you will release the terminals scripts?

Regards

Hi aramil

Happy you like it <img src=\"{SMILIES_PATH}/icon_e_smile.gif\" alt=\"\" title=\"Smile\" /> This will be published quite soon as an intermediate version 0.1.8 RC3 I think. I just need to polish the html output a bit and rjspence is helping me with a little code lifting for the terminal LSL script. And yes of course, the terminal script will be published as well since it is a required part of the component to let it work <img src=\"{SMILIES_PATH}/icon_e_smile.gif\" alt=\"\" title=\"Smile\" />

In this upcoming version, all you need to do is altering the path-to-your-joomla-component in the LSL script. The script will then automatically register with jOpenSim telling its name (= name of the prim), region and location and the component will automatically add it to the list of terminals. Optionally a different listen channel and/or description for the terminal can be entered as well.

What will not work in this upcoming version is, that the component also should automatically check, if a terminal is NOT present anymore. Only a manual removing or disabling in the admin will currently be possible. But I have to search in my drawers a bit (what a mess in there, hehehe) I think I wrote some xmlrpc LSL script once for SL to communicate from website direction inworld that could be used for this purpose as well in case we can adopt it for OpenSim LSL.

Greetz
FoTo50

Hi all,

I thought this worked out okay myself. As mentioned, it helps with allowing the end user to be able to identify themselves in-world in such a way that Joomla will auto sync the accounts through a small script process. Made sense to me. All that is left that I am aware of is just going through the scripts again and making sure that there are no security vulnerabilities. Another reason this is good is that it also opens up the arena for other ideas for inworld<->website type scripted communications for other necessities. Our in-world testing went well on this, and looking forward to trying some other ideas associated with it.

There was nothing wrong with having it the way it was as long as the registrations didn\'t get out of hand, the admin would be manually syncing the user accounts. However, after second thought, why should the admin be doing all of this?

The lsl scripting was fairly straight forward and not at all an issue for this type of scenario. I would imagine a terminal per sim if that. But with the front end work being as it is, to where you can select the link to where the terminals are located, and paste it in chat for a quick click, it just seemed a simple solution that would work well, and in my opinion, it does the job. The terminals auto sync on rezz with Joomla (well mine will), but also a dialog enable, disable menu to take the terminal offline/online, so there are no real configurations to worry about except the channel you want to communicate on.

The script and terminal will be freely open for modification for your own network setup.

Good job on the implementation Foto! If you need me for the documentation project on this... you know where to find me. <img src=\"{SMILIES_PATH}/icon_razz.gif\" alt=\"\" title=\"Razz\" />

Thanks for your thought provoking posts aramil! That is what drives the direction for the fixes.

Now if we can just get search and groups backend implemented.. <img src=\"{SMILIES_PATH}/icon_e_smile.gif\" alt=\"\" title=\"Smile\" />

Thank you,
rjspence