[openstreetmap/openstreetmap-website] Re-arrange login and signup screens as discussed in #4128 (PR #4455)

[Tom Hughes]

@tomhughes requested changes on this pull request.

Mostly looking good from a backend point of view with just a few minor issues but there is one big question around the new logic you've put in for dealing with linking a social signup to an existing account.

Also there's the inconsistent colons on the field labels that already mentioned and @gravitystorm has made some high level design comments in his review and will doubtless have more to say on the UI side before this is ready.

> @@ -70,13 +72,16 @@ def new
       # page, instead send them to the home page
       redirect_to @referer || { :controller => "site", :action => "index" }
     elsif params.key?(:auth_provider) && params.key?(:auth_uid)
+      @auth_uid = params[:auth_uid]
+      @auth_provider = params[:auth_provider]

We're putting both of these in the user object we create which is accessible to the view so I'm not sure we need separate member variables as well?

> @@ -70,13 +72,16 @@ def new
       # page, instead send them to the home page
       redirect_to @referer || { :controller => "site", :action => "index" }
     elsif params.key?(:auth_provider) && params.key?(:auth_uid)
+      @auth_uid = params[:auth_uid]
+      @auth_provider = params[:auth_provider]
+      @verified_email = params[:verified_email]
+
       self.current_user = User.new(:email => params[:email],

I realise it's not new but I'm worried about using `current_user` here because the general assumption is that `current_user` is the current signed in user and the user isn't signed up yet here so this probably needs to be `@user` or something instead - obviously that also needs changes to the view and to the login action as well. Maybe @gravitystorm has more thoughts about whether using `current_user` is wise though?

> @@ -290,8 +241,23 @@ def auth_success
         else
           failed_login t("sessions.new.auth failure")
         end
+      elsif user.nil? && user = User.find_by(:email => email)

I don't think we need `user.nil?` here as we would have taken the previous branch if user was set.

> @@ -290,8 +241,23 @@ def auth_success
         else
           failed_login t("sessions.new.auth failure")
         end
+      elsif user.nil? && user = User.find_by(:email => email)
+        user[:auth_uid] = uid
+        user[:auth_provider] = provider
+        user.save!
+
+        user.deactivate! if user.status == "active" && !email_verified
+
+        if user.status == "active"
+          successful_login(user)
+        else
+          session[:token] = user.tokens.create.token
+          UserMailer.signup_confirm(user, user.tokens.create(:referer => session[:referer])).deliver_later
+          redirect_to :controller => :confirmations, :action => :confirm, :display_name => user.display_name
+        end

This is trying to deal with the case where somebody does a social signup and there is already an account with the email address the social provider returns and it looks problematic to me for a number of reasons:

* If the user already had a different social provider attached to their account this will overwrite it
* If the social provider satisfies our (deliberately weak) definition of providing a verified email then we allow them to attach to the existing account with no further verification but that is very different to allowing creation a new account based on a weak verification
* If the social provider email is not considered verified then we send a normal signup confirmation but the working of that will be a bit odd in this case I think plus we actual deactivate the account until that confirmation happens

There's a definite problem here, that I had a case of only this week, where somebody tries a social signup and they already have an account but I think we need to send a confirmation email in all cases and probably make it a different one saying that we need to confirm the social signup link and just use it to confirm the link rather than doing a deactivate first.

I'm not sure what to do where there is already a different provider attached though though arguably that's fine if we only change the auth provider after email confirmation and the email says we will be replacing the old one.

> @@ -181,11 +181,9 @@ def self.authenticate(options)
       transitions :from => :pending, :to => :active
     end
 
-    # Used in test suite, not something that we would normally need to do.
-    if Rails.env.test?

This is only being removed so that we can deactivate while revalidating an auth id association and as explained above I don't think we can do that so this can then be left as is.

-- 
Reply to this email directly or view it on GitHub:
https://github.com/openstreetmap/openstreetmap-website/pull/4455#pullrequestreview-1861453314
You are receiving this because you are subscribed to this thread.

Message ID: <openstreetmap/openstreetmap-website/pull/4455/review/1861453314 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/rails-dev/attachments/20240204/f744a6fb/attachment-0001.htm>