Need to automatically register new users on a WordPress site with their Second Life® avatar names? This plugin allows you to do so, by exhibiting a script that you can copy and place into an in-world object. Users just need to touch the object to get automatically registered; if they are already registered, they will just get a link to your site.
New users will receive a password via the Second Life Instant Messaging Service, as well as a link to tell them the URL for your site. The new profile will include their avatar name as a login and their SL profile picture (if available via Web) will become their WordPress profile picture. If you have some special meta fields enabled on your WordPress profile, they will be filled in with some data from SL as well (e.g. location).
First of all, please take into account that there is no absolute fail-proof solution. Hackers will definitely be more creative than I am in preventing them to override security to register with your site. If you’re afraid they might subvert your system and register accounts on your WordPress site, DON’T USE THIS PLUGIN!
If you’re bold enough to try it out, read on.
This plugin was designed for having multiple locations for SL residents to register with your WordPress site. The caveat is that this will require you to provide them with the LSL script which you copy from the plugin’s main page. Of course the script can be made no-modify and no-transfer, and so nobody will be able to read it, but we all know there are means to get access to it if someone really, really wants to (specially on OpenSim-based grids).
So there are four levels of protection in this plugin. Please note that three of them are possible to be forged; the fourth one is a bit more tricky but not totally impossible to subvert; how you use them all together is up to you, depending on how widespread and flexible you wish residents to register with your WordPress website.
The first level is a cryptographic signature. This is set from the plugin’s admin page (actually you have two signatures; one long string with random garbage, and a 4-digit PIN code). All in-world requests need to be signed or the plugin will refuse access; this prevents anyone not knowing your secret key and PIN and trying to simply send a forged HTTP request to be refused access.
But keys can be compromised. Your first line of protection is simply to delete the culprits — all objects registered with your WP site will be listed, and you can simply delete the objects from the “Objects” tab, and change the keys. The plugin will also send a remote delete request. Of course, a hacker having access to the script will be able not only to figure out the original keys but also to remove the code for the remote deletion command. And if you have spread out registration objects all around SL and OpenSim grids, changing the keys will prevent all objects from working, which might not be feasible.
So the second level of protection is to restrict registration objects to certain avatars (we’ll assume they’re the only ones you deem to be legitimate). You can, for instance, just limit objects to be owned by you and your close friends or associates (or just your alts). This means that a hacker will not be able to create an object and place a hacked script inside; SL (and OpenSim) send the object owner’s name, and the plugin can refuse requests from anyone not on the list. On the security page, this is the first area (Allowed avatars (for registration objects)). There is no limit to the list.
This can be easily subverted: if a hacker knows your avatar name and knows what keys and PIN are in use, they can register on a OpenSim grid with your name and continue to create accounts on your WP site.
A related protection is to ban some avatar names from ever registering again. This is the second area. Note that this doesn’t affect who can create registration objects and register them with your site; it prevents avatars from creating a login on your WordPress site. A banned avatar will be unable to create a login ever again, but they might still have an active registration object, and this area will not prevent others from registering via their object (meaning that the hacker will be able to create alts to log in).
Also, please note that things like avatar names and so forth are actually headers on the HTTP requests made by the in-world object, and these are sent by the SL grid itself (or the OpenSim grid). What this means is that hackers cannot launch attacks from within a grid (specially one that is not under their control), but they can create a piece of software that “pretends” to make a request from the grid but is actually running on a webserver with hacked headers.
The last level of protection tries to avoid the pitfalls of the three first protection levels. You can add a list of authorised domain names (full or partial) or IP addresses from which connections can be initiated. By default, when you install the plugin for the first time, it will only accept connections from SL’s grid — all servers in it should look like “simXXX.agni.lindenlab.com”, so filtering by “lindenlab.com” should only allow objects on the SL grid to register — all other grids will be banned. This will also prevent hackers from using their own webservers; headers can be forged, but the IP address from which the hacker is actually connecting is much, much harder to forge (I won’t claim it’s impossible, but it’s beyond most human beings 🙂 ). Even a hacker using a proxy or an “anonymiser” service to mask their original IP address will not work: you might never figure out where they are actually connecting from, but the plugin will know the request doesn’t come from Second Life (or one OpenSim grid you actually trust), so it will block it nevertheless.
Instead of blocking a whole grid, you can just selectively accept requests from specific servers (e.g. only from “simXXX.agni.lindenlab.com”). Under OpenSim grids, this might not work as expected, because the same server might actually host a lot of different sims under the same IP address, and it will not be possible to differentiate between them. Also note that you can use IP addresses and not domain names, for quick-and-dirty OpenSim grids who never even bothered to register a DNS address and just have IP addresses (like home-run grids). Linden Lab’s sim servers should all be accessible via DNS, so it’s safer that way; but they might shuffle sims around. The way to figure that out is by taking a look at “About Second Life”, which should give you the DNS address of the sim you’re on.
So what would be the maximum level of protection?
- Making sure that nobody knows your keys and 4-digit PIN
- Restricting the registration only to yourself
- Limit the access from a single grid or even a single sim
Again, this is not 100% secure, but should give you pretty much the same level of protection that WordPress itself provides: after all, if it’s too difficult to subvert this plugin’s authentication system, a hacker might try to register directly to your site, bypassing this plugin. These days, this is rather hard to do as well.
Also note that new users are created with the “Subscriber” role. This gives them the ability to post comments and create a profile, that’s all. Of course, the ability to post comments also allows them to spam you…
Hackers might also try to launch a Distributed Denial-of-Service attack against you, but, again, this is pretty much impossible to do from within SL (LL’s grid is proofed against launching DDoS attacks from in-world). It can be done outside SL, but it’s far easier to attack the WordPress site itself.
- After installing the plugin, if you’re using a cache manager (e.g. W3 Total Cache) make sure you add register-avatar.php and register-object.php to the exception list, or you’ll get multiple registrations with the same name!
- Go to the Settings menu and look at the option for “SL User Create”. You should be shown a pre-formatted LSL script.
- Launch Second Life.
- Create an object in your land. Make sure that scripts are active!
- Right-click to open the object’s Build popup, and go to the Contents tab.
- Create a new script inside (just click on the button).
- Delete everything in that script.
- Now go back to the WordPress admin page you’ve opened, and copy the script and paste it inside your LSL script in Second Life.
- Save the LSL script in Second Life; it should recompile.
- The LSL script will now try to contact your blog and register itself.
Now any avatar wishing to register for their blog will only need to touch this object and get immediately registered. You can have multiple objects, on several sims, even on different grids, and owned by different users.
Avatar names have to be unique across your blog, which means that the same user cannot register from different grids with the same name (but they can change the password if they forgot it, and don’t need to log in back to their original grid). Note that WP logins might not work with dots in it and might get be replaced by underscores.
You might also try using https://wordpress.org/extend/plugins/wp-valid-username-normalizer/ to get invalid WP usernames to be able to log in.
From 0.2.0 onwards there is a security page which allows a few options to limit access from potential hackers.
- I get errors when the in-world object tries to contact the external URL!
A few people reported that their hostname is nowhere near what WordPress thinks it is, and so, obviously, registration will fail when the in-world object tries to contact your WordPress site.
0.2.4 changed the way the hostname is “figured out”, but if it still gets it wrong, change on the LSL script what appears under string http_host = “” Note: no trailing slashes.
- Can I place multiple objects for registration?
Yes! The admin panel will list the currently active objects, where you can also delete the ones that are inactive. Each object will count how many avatars have been registered through it, so that you can keep track of which objects have been attracting more registrations.
You’re also welcome to edit the LSL script, if you’re talented enough, to personalise the user experience.
Objects can also be on different grids, so long as these are running OpenSim 0.7.0.2 or more recent.
- One user forgot the password. What now?
Ask them to touch the object again. It will give them a popup box where they can reset the password and have it sent to them by Instant Message.
Note that this will work on any object registered with your site, no matter where it’s placed (yes, even on a different grid!).
- Can I use this on my OpenSim grid, too?
Yes, you can. This was tested on an OpenSim grid running 0.7.0.2; earlier versions might not work. Please note that if you have registered on one grid with your avatar name, and then register on a different grid with the same avatar name, you’ll just change the password — this plugin assumes that avatar names are unique across grids (because WordPress logins have to be unique).
Some errors are less obvious on OpenSim and difficult to track; this has to do with the way error messages are passed back
Also, the auto-deletion feature might not work well under OpenSim (i.e. it gives an error, but in some cases, the object will actually disappear).
Contributors & Developers
“SL User Create” is open source software. The following people have contributed to this plugin.Contributors
- Fixed a security issue: non-admin users could see the LSL script
- Fixed missing <?php (was just <? )
- Added some extra validation code for usernames. When the SL name -> WP username conversion fails, it aborts
- Changed the way that the hostname is figured out for the LSL script
- Started some development to allow users to add their email addresses from within SL
- Updated FAQ!
- moved banner and screenshots to assets; trunk is now empty and “stable tags” is used instead
- Added llStringTrim() to the LSL script after receiving a remote message. Thanks to ANSI Soderstrom for spotting that this sometimes failed due to extra space on some web servers.
- functions.php was missing from the distribution! Thanks to ANSI Soderstrom for pointing it out to me.
- Add option to ignore signature (less safer, but good for debugging/testing purposes)
- Security configuration module implemented: limit avatars to register objects with our site; ban avatars from registering with our site; limit hostnames/IP addresses
- Fixed minor script issues to work with OpenSim 0.7.0.2+
- Users already registered, when touching the object again, will now get a popup allowing them to reset the password instead of silently failing to register them again
- Now new users will have an email address with the site’s domain name appended. This might be useful for some services that will provide SL residents with mailboxes
- Updated registration object timestamp every time a new avatar registers or changes their password
- Added required screenshots for WP
- Retrieves avatar profile information from world.secondlife.com/resident/ and puts it into WP profile
- Simplified admin page: now when deleting an object, it also sends a llDie() to it
- Added instructions tab
- Translations for Portuguese included
- Avatars get registered with fake email address, because logins wouldn’t work if they hadn’t one
- Registration IM now shows URL of the website they’ve registered to
- Added two additional strings to allow for minimal security; they still cannot be saved thanks to a nasty bug…
- Added support to multisite installs (via a meta key)
- First release. Lots of code borrowed from my other SL plugin, Online Status inSL