Viewer Authentication

Note: If you would like to discuss the changes stated in this page, please use the discussion tab at the top. We are reading it and answering your questions there and will update the wiki as needed. Thank you!

Note: This page primarily describes Linden employees' view on the issue that some open source developers have expressed concerns against. If you want to know the open source developers' view or related backgrounds, you are advised to read not just this page but also the associated discussion page and Viewer Authentication Critique page.

Note: The first note above was written by a Linden, and the word "we" refers "Linden employees". The second note (as well as this note) was added by a resident Alissa Sabre for clarification.

Viewer Authentication

Fairly soon, Linden Lab is going to introduce new form of logging in. The current process requires an xml-rpc call from your viewer to our servers that runs along an inflexible code-path that is difficult to maintain. This process will change to a web-based path that is easier to maintain and will allow us easier access to tools for making logins smarter and furthering our anti-fraud efforts.

What Changes For You?

You will see one change when this is released. The viewer's login page will be web-based. It actually won't look that different from the current interface and allows all the same functionality.

(Note: The optional "Go Inworld!" page mentioned here before will be a part of a separate release as it requires more work.)

Keep in mind that if you are developing a third-party application to access Second Life, we will be keeping our old login methods intact until you catch up with the new process - at which point we will shut down the old pathways.

Frequently Asked Questions

"On the viewer's login screen, I'm given the choice of where I want to log into. Will I still have that option?"

Yes. This functionality will be the same both in the viewer's login and on the website's login.

"I use Second Life from a computer that is not mine. How does this affect me?"

Everything works the same as before.

"Why aren't you fixing bugs? I don't care about login!"

Linden Lab has a team of developers who are constantly fixing bugs in Second Life. However, we also have developers who work on the website, the servers, and specific issues such as security, billing, and fraud prevention. Viewer Authentication is being developed in order to extend the ability of our logins such that they can take advantage of new fraud prevention measures, future account security measures, and be placed in a more flexible and easier to access code-path. Fixes to the website's login can be instantly ported to the viewer's login and vice versa.

"What happens when I want to use the First Look client or some other third-party application?"

Until they are brought up to speed with the new login process, these extra applications will still be able to use our old login procedure.

Technical Overview

In order to maintain backward compatibility, there will initially be several ways to log in:

• Login from legacy viewer using current XUI and name/password.
  • Until they are brought up to speed with the new login process, other clients will still be able to use our old login procedure. This transition is expected to complete by beginning of February, at which point a mandatory update will be required.
• Login from a new viewer from login screen
  • Login form removed from screen XUI
  • Web login modules added to login screen splash page
  • Splash screen saves and passes web login key to viewer using a redirect
  • Viewer logs in with name/web_login_key
  • May be deprecated eventually, but because of pushback from sldev, we decided not to
• Login from InWorld page on Second Life website (https://secondlife.com/inworld/index.php)
  • Go Inworld generates and persists web_login_key, returns it coded into secondlife:// url.
  • OS launches viewer associated with secondlife:// (last used viewer, or last installed viewer).
  • Viewer parses url, logs in with name/sid

The common web mechanism is as follows:

• Website confirms (cookie) that resident is logged in by filling in user name fields if they are
• Website also takes many query parameters to automatically fill in fields in the form
• Upon receiving POST, website generates a temporary, single use web_login_key and persists it to web_login_key web store on central backbone
• Website redirects to the continuation url provided, and appending web_login_key as a query argument at the end
  • For login via website, continuation url: secondlife://viewer/login?firstname=;lastname=;session_id=;location=?'
  • For login via viewer, continuation url: about:blank?redirect-http-hack=($URLENCODE(secondlife://viewer/login?firstname=;lastname=;session_id=;location=?'))
• Viewer catches or launches and uses user name and web_login_key to send to login.cgi
• login.cgi checks session id and allows the user in

Additional info:

• Logging into a custom/internal grid appears to require two secondlife.exe parameters;
  • -loginpage <URL>, the login page displayed to the client
  • -loginuri <URI>, the address that the client should look for the login.cgi equivalent

Additional Note:

• The public login forms on secondlife seem to send something like, secondlife:///app/login?first_name=*firstname*&last_name=*lastname*&location=*location*&grid=Agni&web_login_key=*UUID*

See also

Login Protocol - general summary of login protocols