with version 1.2.0 @data is not passed to the omniauth_external_window.html.erb
yortz opened this issue · 2 comments
Hi, first of all, let me say that I have been using devise token auth since 2017 and I have integrated various types of authentications (with regular username and pwd) and other custom omniauth strategies with success. I have been using this library to authenticate with various web client apps (ember, react) flawlessly. Now after all these years, I decided to update the version of devise token auth from 1.1.0 to 1.2.0. I am on rails 6.1.7.1.
I have been running the current specs for my code base and out of 509 examples, it seems that I have only 1 spec failing; by having a look at what is going on, it seems that for some unknown reason, the spec is failing since the response.body for the callback response is an empty string and the @data coming from the render_data(message, data) method in the omniauth_callbacks_controller.rb is not passed to the omniauth_external_window.html.erb view (as instead it was happening with version 1.1.0). This is totally weird, since if I directly debug from inside devise_token_auth and I inspect what is going on in the render_data(message, data) method my @data is there, here is an example of calling @data.to_json from the method
"{\"auth_token\":\"ABCDERWEEWWEFR\",\"client_id\":\"DAFAFDFDSFDSF\",\"uid\":\"123456\",\"expiry\":1684595450,\"config\":null,\"email\":\"user@email.com\",\"username\":\"username-123456\",\"fullname\":\"User name \",\"id\":1,\"created_at\":\"2019-12-18T13:48:54.252Z\",\"updated_at\":\"2023-04-20T15:10:50.346Z\",\"deleted_at\":null,\"invitation_token\":null,\"invitation_sent_at\":null,\"invitation_accepted_at\":null,\"invitation_limit\":null,\"invited_by_id\":null,\"invited_by_type\":null,\"invitation_created_at\":null,\"show_archived_experiments\":false,\"avatar\":null,\"url\":null,\"location\":null,\"laboratory\":null,\"show_archived_reagents\":false,\"show_tasks\":\"all\",\"provider\":\"idplus\",\"persistent_allow_password_change\":false,\"investigator_id\":null,\"show_archived_data\":false,\"allow_password_change\":false,\"investigator_lock\":null,\"inst_assoc\":\"INST\",\"indv_identity\":\"REG\",\"indv_identity_method\":\"U_P\",\"inst_assoc_method\":\"CSCREATED\",\"inst_acct_id\":\"1243423\",\"inst_acct_name\":\"Maintenance \",\"inst_acct_image\":\"http://domain.com/institution.JPG\",\"path_choice\":false,\"policy_success\":[\"urn:com:domain:idp:policy:product:indv_identity\",\"urn:com:domain:idp:policy:product:inst_assoc\"],\"message\":\"deliverCredentials\"}"
but to my great surprise, it seems that when I am redirected to auth/provider/callback page, this page is always empty, no js is executed (I tried to put a console.log in there to see if I could debug something from the view), I even tried to manually place some plain text in the body to understand if I could at least have the @data included in this page by using simple ERB but no matter what, this is always rendering an empty page: the @data is not passed to the view and the sign in is successfull, since if I inspect the current user, this user is signed in and authenticated to the rails app (the sign in count is updated in my db table) but the @data is not passed anymore in the view with version 1.2.0 as it was happening with version 1.1.0 and no js is executed, I am totally stuck on this and I do not understand if this has anything to do with the new changes in the version 1.2.0 or if this has something to do with the version of rails, has anyone by chance experienced this same type of issue with version 1.2.0 of devise token auth? Any kind of support on this would be highly appreciated, thanks in advance!
I tried with version 1.2.1 and the result remains the same, this is really weird since the callback is successfully returning the auth hash, I even got the code passed as param to the callback and this sets the session, the user is successfully signed in, all auth params are in place, I even tried to add back sprockets since I noticed this has been removed thinking this was the cause of the issue, but no way to get past this weird behaviour. The strange thing is that if I add an override for the external omniauth page, or if I directly try to edit the one for the gem (by mounting devise_token_auth in my Gemfile to use the local version I cloned on my machine), no updates are reflected in the page, so let is say that for example I am doing something like this in my custom override
#app/views/devise_token_auth/omniauth_external_window.html.erb
<!DOCTYPE html>
<html>
<head>
</head>
<body>
<p>Hello World</p>
</body>
</html>
Instead of seeing at least the text comment in the template, it literally always renders an empty view, this is totally weird, in this way I am prevented to have the @DaTa passed into the view and then do the redirect to my FE app, by the way no sort of js is triggered in this page if I include any inside of a <script> tag I am totally stuck on this...
Ok so, to answer myself, and hoping this would save some time to other people, after 2 days spent investigating this issue, I have found out that somewhere along the way during the subsequent versions bumps from 1.1.0 to 1.2.1 - yes I just updated to the latest stable instead of sticking to 1.2.0 - the way that omniauth callbacks are handled was changed. In previous versions, the omniauth callback controller would automatically render a template. However, in 1.2.0, this behavior was removed, so to fix this I had to include into my OmniauthCallbacksController the following
include ActionView::Layouts
include ActionController::Rendering
makes sense, since I am using a rails api only app and without those includes any rails api only app will not render, since ActionView::Layouts provides Layout and include ActionController::Rendering provides template rendering. With them, I can render *.html.erb . With those changes to my callback controller everything runs fine, and all specs are passing and I am now using latest devise_token_auth stable version. I would appreciate some quick feedback from any maintainer, to understand if what I am supposing is correct (and maybe is there a specific commit that removes the previous behaviour). I will leave this issue open, in case anyone would face the same issue as me.