On v1.8.0.beta4 +116, users are seeing errors trying to sign in using an
auth_provider we wrote.
Here’s the trace:
/var/www/discourse/app/models/user_auth_token.rb:16:in `generate!' /var/www/discourse/lib/auth/default_current_user_provider.rb:133:in `log_on_user' /var/www/discourse/lib/current_user.rb:18:in `log_on_user' /var/www/discourse/app/controllers/users/omniauth_callbacks_controller.rb:125:in `user_found' /var/www/discourse/app/controllers/users/omniauth_callbacks_controller.rb:104:in `complete_response_data' /var/www/discourse/app/controllers/users/omniauth_callbacks_controller.rb:63:in `complete'
The auth_provider is supporting authenticating through LTI from EdX (our code here: discourse-edx-lti/lti_authenticator.rb at master · mit-teaching-systems-lab/discourse-edx-lti · GitHub). This is a bit different than an OAuth provider flow. In our case:
- EdX sends a POST to
/auth/:provider/callbackwith a bunch of params
auth_providervalidates those params, and then grabs an email address out of them
auth_providefinds or creates a User by that email address. This enables there being no “sign up” flow for users (that’s the whole point of LTI).
This works great for existing users, but is trickier for first-time users. The
omniauth_callback_controller has assumptions about the sign up/log in flows, and expects a
User to be set on the
auth_result. So for first-time users we pass it a new User record that hasn’t been saved yet, and it saves it. I suspect something about the
UserAuthToken change is problematic, or maybe that the
user.save line is failing for some reason.
The most obvious thing seems to directly create the new User record in the
auth_provider, and work around this, since I suspect my use of
auth_provider is not what the OmniAuth controller code expects. Also, apologies if this is the wrong place to ask about this and if it’s too close to a question about developing a new feature than it is to a proper bug report. Thanks!