How long a user has been using our product is a very important aspect of how much other users should trust their answer in the forums, but if we use single sign-on, then that value doesn't properly reflect how long they've been using our site. And if we migrate from existing uservoice signups to single signon signups, then it doesn't even recognize how long they've been using uservoice, since it resets to the first time the come over via single sign-on.

Therefore I suggest that you add an additional optional parameter to the JSON blob we send over as such:

user_since - timestamp (optional) - Date when this user started using your service/product. GMT biased.

I understand that the login system is meant to help new users, but having the password below the e-mail field is a universally accepted convention that has 100% mindshare.

As an admin, I've created 5+ new accounts, accidentally, by misspelling my rather long e-mail address. While this in itself isn't a huge issue, I generally finish typing my password into the 'name' field before the ajax has time to complete.

Which results in my password being made public. I'm sorry, that's really across the line.

If the ajax doesn't come back in time, the default behavior should *NEVER* be to use the password field for the 'name' value. That's just unacceptable. For one, the terms of use were never displayed to the user. Second, the user entered their password into an field which displayed "******" as if it were a password field.

The AJAX request MUST change the ID of the password field so the server knows whether the user entered the value as a password or as a name. And if the user entered it as a password, well, they can be prompted with an additional dialog that asks for their name and shows them a terms of use link.

This isn't about making the AJAX more responsive, it's about closing the security **** that occurs in the meantime. Even a 10ms request is too long for this kind of behavior to be allowed, let alone the 5000ms that I get from Italy.

Currently Uservoice uses a custom workflow to resolve login redirection requests. For services that expose an oAuth interface it would be far better to be able to route the user through oAuth (which would give a far more consistent user experience, and makes SSO support almost automatic for anyone with an oAuth provider.)

This should be relatively easy to implement on the UserVoice end of things. A set of fields would need to be provided in the admin console allowing the administrator to specify the client_id, client_secret, and scope. URLs would also need to be indicated for the authorization request, the token request, and some API that UserVoice can use to exchange the access token for an SSO key (or the the user information directly, since encrypting for transit is redundant at this point).

Obviously, oAuth should just be an OPTIONAL alternative to the current flow, since the current flow works great for anyone not interested in running an oAuth provider.

I'm used to typing in my email address, pressing tab, and then my password, then pressing enter (as annoyingly the browser doesn't save my password). However, on one occasion, I mistyped my email address without noticing, so moved onto the account creation process without noticing.

I then typed my password in the name field, pressed enter, and an email went out to all subscribed users with my comment, but my name was my password - oops!

I think the process should be notably different to prevent this happening - or don't use AJAX to submit the password to allow the browser to remember the password.

Other than that, brilliant service, thank you!

We are finding that our customers are very confused about the "need" to sign-in when they visit our knowledge base: http://support.inqscribe.com/knowledgebase

Our product is desktop software, so when they see this, they think they need to sign in in order to use the knowledge base.

Is there a way to either:
1. Remove the link from the knowledge base page, or give us an option where we can turn it off, or
2. Explain why the sign-in is necessary (or that it's optional), or
3. Move it somewhere less prominent so that users don't think that they HAVE to sign in?

Thanks,
Ben