+1-888-365-2779
Try Now
More in this section

Forums / Upcoming Features / Authentication changes in Sitefinity 10.0

Authentication changes in Sitefinity 10.0

45 posts, 0 answered
  1. Stephen2
    Stephen2 avatar
    94 posts
    Registered:
    05 Feb 2012
    23 Nov 2016 in reply to Atanas
    Link to this post

    This is great news, very exciting!

    But, there is 1 thing still not right...

    It will not be possible to change the email once created.

     

    You definitely have to find a way to allow this to work!  One solution may involve storing the Username as GUID, and modifying Login controls to query Email field instead of Username.

    OR, what we have done sometimes, a 2 step login process:

    1) var userFound = (Lookup user by email typed in)

    2) If match, perform login with userFound.UserName, password typed in

     

  2. Ryan
    Ryan avatar
    6 posts
    Registered:
    20 Nov 2012
    23 Nov 2016 in reply to Atanas
    Link to this post

    Atanas said:

    It will not be possible to change the email once created.

    Am I reading that correctly?  You're not going to allow a user to change their email after they have an account in the system?  If I understood that correctly, that's a huge stumbling block.  Email should be unique in the system and you should be identified by email address, but it shouldn't be readonly.

    Can you provide more clarification on that point, if we're understanding you properly and if so the reasons why that was chosen?

  3. Steve
    Steve avatar
    3037 posts
    Registered:
    03 Dec 2008
    23 Nov 2016
    Link to this post
    What would the technical reason be for that?  If the username is just an entry in the DB, the UserId is the important part...?
  4. Arno
    Arno avatar
    249 posts
    Registered:
    08 Sep 2010
    23 Nov 2016 in reply to Ryan
    Link to this post

    That's unacceptable indeed. It will force users to create a new account if their e-mail changes, and loose all account history (in our case at least forum post history).

    One person should have one account only, and there should be no reason, ever, to create a new account.

  5. Jeff
    Jeff avatar
    0 posts
    Registered:
    23 Jul 2013
    30 Nov 2016 in reply to Atanas
    Link to this post
    Atanas said:

    The second reason to take this approach is the fact that it is not a common case to login with different accounts to single site. Do you really think this case can be useful? 

     

    We just redesigned our login system for several reasons

    1. We had multiple accounts with the same email and different login methods. Many of our users would log in with twitter one day, yahoo the next, google and facebook and them create a local account. I don't think this was intentional in all cases as people just forgot if it was google or facebook login they used.

    2. We were using openID 2.0 and wanted to modernize our accounts.

    3. We wanted to integrate with sitefinity better.

     

    We ended up building an identityserver3 server that support google, facebook, twitter and local accounts and all our apps use owin  OpenIdConnectAuthentication() with some custom patches (there are bugs in the way it manages cookies).

     

    The plan was to deploy a man in the middle STS that translated from OpenID connect so having this built into 10.0 means I will leave this integration point out till later.

     

    The big stumbling point is if the new system will pull common fields like email (it's all we collect) so users can sign up for sitefinity newsletters and such without retyping their email.

     

    As for trusting providers, google will tell you if it has verified the email. Facebook will not let you log into other sites until you verify. Twitter doesn't provide an email so we let them log in and then block them until they click a link in the email. 

     

    The issue we are typing to solve still is how to allow AD authentication for the admin but social for the front end.

     

  6. Jeff
    Jeff avatar
    0 posts
    Registered:
    23 Jul 2013
    30 Nov 2016
    Link to this post

    How did you solve the issue where there are conflicts

    user 1:

    username(not email) : email2@example.com

    email: email1@example.com

    password: password

     

    user 2:

    username: email1@example.com

    email: email2@example.com

    password: password

     

     

    So someone shows up and enters email1@example.com and password. Who just logged in? We actually had this case in our user database.

    My solution was to trow out all the usernames and passwords (our old database has a hash that can be brute forced with a bitcoin farming machine) and force a password reset based on email when the user next came back.

  7. Atanas
    Atanas avatar
    0 posts
    Registered:
    08 Jul 2016
    02 Dec 2016
    Link to this post

    Hello,

    We did some research this week about email/username change and we decided to allow this operation. We will keep username and email always sync in the database for new/updated users.

    Username will be removed as parameter and only email will be used at API level. The username property will still be available and API will take care that it will always be synced with the email.

    All backend user and profile pages will contain only email field.

    @Jeff: Here is the algorithm that we will use for login:

    1) Check input email/username field in the DB. If only one user with this email exists, then use it for login. If not, then:

    2) Check input email/username field in the DB. If there is no such email in the db, check in the username filed. If such user is found, use it for login. If not, then:

    3) If no username or email exists in the db, return invalid user/pass error.

    4) If more than 1 email exists in the email field in the DB, return error.

    So Jeff, in your case, user 1 will login.

     

     

  8. Stephen2
    Stephen2 avatar
    94 posts
    Registered:
    05 Feb 2012
    04 Dec 2016 in reply to Atanas
    Link to this post
    Great choice!  Thank you
  9. Steve
    Steve avatar
    3037 posts
    Registered:
    03 Dec 2008
    05 Dec 2016
    Link to this post
    Agreed, thx for listening team, excited about this!
  10. Dimitar
    Dimitar avatar
    1 posts
    Registered:
    10 Mar 2011
    14 Dec 2016
    Link to this post

    Hello everyone,

    We have shared previously the plans for Sitefinity 10.0 -

    • The authentication will continue to support both email and username 
    • Registration of new users will be with email only (the username will be filled automatically with the email in the database).

    There is a question to everyone:

    Are there any requirements for user registration with username and not email? No matter if those are past or future projects.

    Thanks in advance for your feedback.

  11. Steve
    Steve avatar
    3037 posts
    Registered:
    03 Dec 2008
    14 Dec 2016 in reply to Dimitar
    Link to this post
    I have never had the requirement for a site to have username and not email... 100% of the time (here) we have to hack in making the email the username (or visa versa)  in an event or overriding a widget or something.
  12. George
    George avatar
    17 posts
    Registered:
    16 Jan 2014
    14 Dec 2016
    Link to this post
    So we don't register users - so not sure it'll matter, but all of our users come from our AD integration.  That has a distinct separation between Username and Email.  How will the new process handle the mapping of the fields in an LDAP/AD integration?  Will the search process change on the User screens as well? 
  13. Atanas
    Atanas avatar
    0 posts
    Registered:
    08 Jul 2016
    15 Dec 2016
    Link to this post

    Hi gyus,

    There is some update for email change functionality, which will be implemented in Sitefinity 10.0.

    - Email change will be possible only for internal users (the ones, first registered with email/password). Email change should also be confirmed with the user password!

    - Email change will not be possible for external users (the ones, first registered with external provider). Reason for that is that email is external key to the provider, and if changed, the account will no longer be accessible.

  14. Craig
    Craig avatar
    82 posts
    Registered:
    07 Apr 2009
    09 Feb in reply to Georgi
    Link to this post
    Will the authentication changes in Sitefinity 10 support IdentityServer4 upon release or at some point in the near future?
  15. Atanas
    Atanas avatar
    0 posts
    Registered:
    08 Jul 2016
    10 Feb in reply to Craig
    Link to this post

    Hi Craig,

    Sitefinity 10 will not support IdentityServer4 as it targets ASP.NET Core.

    Basically, IdentityServer3 and IdentityServer4 have same functionality, the difference is the target platform.

45 posts, 0 answered
1 2