omar28
commented
8 years ago I advise you to use active model serializer v0.9
Closed JamesChevalier closed 8 years ago
omar28
commented
8 years ago I advise you to use active model serializer v0.9
gregmalcolm
commented
8 years ago I ran into the same issue. I'm using later 0.10.0.x too because I'm using JSON API which works better with Ember. Going back to Serializer v0.9 is not really an option.
JamesChevalier
commented
8 years ago I thought v0.10.0 of active_model_serializers resolved this issue, but I was wrong. With active_model_serializers version 0.10.0, the API response body is correct but the headers lack the access-token and have an incorrect client value.
They're allowed:
Access-Control-Expose-Headers: access-token, expiry, token-type, uid, clientThey're just not present.
HTTP/1.1 200 OK
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
access-token: Ge5GECWjOJ2yPMbtyVCwWj
token-type: Bearer
client: -s_IOgzIlrBEHXQaLi6bip
expiry: 1464796126
uid: person@domain.com
Content-Type: application/json; charset=utf-8
Cache-Control: no-store, must-revalidate, private, max-age=0
X-Request-Id: 2b726u1d-1105-4g59-840g-9ej03e123769
X-Runtime: 0.344088
Access-Control-Allow-Origin: http://127.0.0.1:8080
Access-Control-Allow-Methods: DELETE, GET, OPTIONS, PATCH, POST, PUT
Access-Control-Expose-Headers: access-token, expiry, token-type, uid, client
Access-Control-Max-Age: 1728000
Access-Control-Allow-Credentials: true
Vary: Origin
X-MiniProfiler-Ids: ["l0omufwcolearmecaf1d","yv3ryhiy10013kcot2hq","kqwhy2kn4ukr5th70708","y2ldl9u8ol0srzbrr3m5","ymw9d8fhq7jrb4xz63ni","4qopmbn0c8invivqrs6l","mhec2hye8m8zbqlcdrq5","fzxwko8ufjwxeusf69gu","nbuswnusuu801jtklhy6","9q9lengeyugwz63pvnh7","5pmibt5jzy5uubr3gmfx","wz78cgygat50qfselhsi","a80v42x7ivf0wc8yj1fg","bi9y9xo1e7qz318a9eab","vpe4qp2vax5hm6gtvsjt","193k3dyh2dvq0oefj0kq","mu0bl4b87djnutg0nymm","era8cbby2yv8zscbe0so","ttqkw0osxcb1v39nl053","4xha7g9im9bdun98vtx8"]
Set-Cookie: __profilin=p%3Dt; path=/
Connection: close
Server: thinHTTP/1.1 200 OK
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
token-type: Bearer
client: default
expiry: 1464789869
uid: person@domain.com
Content-Type: application/json; charset=utf-8
Cache-Control: no-store, must-revalidate, private, max-age=0
X-Request-Id: 0cce6213-e4b3-43h0-81w9-c066301b29d4
X-Runtime: 0.342584
Access-Control-Allow-Origin: http://127.0.0.1:8080
Access-Control-Allow-Methods: DELETE, GET, OPTIONS, PATCH, POST, PUT
Access-Control-Expose-Headers: access-token, expiry, token-type, uid, client
Access-Control-Max-Age: 1728000
Access-Control-Allow-Credentials: true
Vary: Origin
X-MiniProfiler-Ids: ["yv3ryhiy10013kcot2hq","kqwhy2kn4ukr5th70708","y2ldl9u8ol0srzbrr3m5","ymw9d8fhq7jrb4xz63ni","4qopmbn0c8invivqrs6l","mhec2hye8m8zbqlcdrq5","fzxwko8ufjwxeusf69gu","nbuswnusuu801jtklhy6","9q9lengeyugwz63pvnh7","5pmibt5jzy5uubr3gmfx","wz78cgygat50qfselhsi","a80v42x7ivf0wc8yj1fg","bi9y9xo1e7qz318a9eab","vpe4qp2vax5hm6gtvsjt","193k3dyh2dvq0oefj0kq","mu0bl4b87djnutg0nymm","era8cbby2yv8zscbe0so","ttqkw0osxcb1v39nl053","4xha7g9im9bdun98vtx8","7pesyrq3surtsdhnghpa"]
Set-Cookie: __profilin=p%3Dt; path=/
Connection: close
Server: thinI think the key here is that the client value is default in the failing example.
augustosamame
commented
8 years ago Downgrading to version 0.10.0.rc4 fixes the issue
Indicate this in your gemfile:
gem 'active_model_serializers', '0.10.0.rc4'
JamesChevalier
commented
8 years ago Hi @augustosamame thanks for trying to help out on this issue! Unfortunately, this task covers the fact that rc4 is functional and downgrading to resolve the problem is a workaround not a fix.
Development is going to continue over at active_model_serializers (they've already moved past the release candidate stage for the 0.10.0 version that we're discussing here), so pinning that to an older release candidate version is only going to cause more problems down the road.
The good news is that there have been improvements in the level of functionality. This issue was originally reporting that the whole response was bad, but now the issue is with two particular header values not making their way out.
Thanks again!
steveclarkin
commented
8 years ago Just curious if there's been any updates on this? We're running into this issue as well when DTA is configured not to change tokens on each request.
config.change_headers_on_each_request = false
We got around this by implementing support for changing tokens in the client, which is fine.
However, we've now discovered a much more serious issue (introduced when using AMS 0.10.0.rc5 and later) that introduces a security hole.
If you post to /auth/sign_in with a valid email, but incorrect password, you get a 401 (expected), but you also get a valid auth header (access-token, client, uid, expiry) (definitely not expected!).
Rolling back to AMS 0.10.0.rc4 appears to fix it, but as suggested above, this is only a workaround, not a solution.
Uelb
commented
8 years ago I actually handled it by a little tweak (not the perfect solution though...), but it works for me now with this configuration : activeadmin 1.0.0.pre2 from git://github.com/activeadmin/activeadmin.git (at master@0ac35b7) devise_token_auth 0.1.37 from git://github.com/Uelb/devise_token_auth.git (at master@7c19493) (Uelb) devise 4.1.1 https://github.com/Uelb/devise_token_auth/commit/7c19493e5143408a4f2fb42b65164f4713b8f112 The problem with this code is that I create the token anyway, even if the user has a wrong password, I just don't send it. It's ok for me now but I will think about a better solution when I have some time to 🐵 .
JamesChevalier
commented
8 years ago I just updated devise_token_auth to version 0.1.38 and active_model_serializers to 0.10.2 and it looks like things are working out OK!
booleanbetrayal
commented
8 years ago Great! Going to close this now. Can re-open if needed.
AbdullahAs
commented
7 years ago I'm facing the same issue with (devise_token_auth 0.1.39), (devise 4.2.0) and (active_model_serializers to 0.10.2), I downgraded to 0.1.38 as per @JamesChevalier comment but still the same!
Rendered ActiveModel::Serializer::Null with Hash
BrahimDahmani
commented
7 years ago @AbdullahAs +1
godinezb
commented
7 years ago Facing same problem with 'devise_token_auth', '0.1.39' and 'active_model_serializers', '0.10.3', I have downgraded to 0.1.38 but the problem it's still there. I'm getting:
AppUser Load (0.3ms) SELECT "app_users".* FROM "app_users" WHERE "app_users"."uid" = $1 LIMIT 1 [["uid", "somemail@mymail.mx"]]
Completed 500 Internal Server Error in 117ms (ActiveRecord: 1.2ms)
NoMethodError (undefined method `find_by_uid' for #<Class:0x007f9db45a8fa8>
Did you mean? find_by
find_by!
find_by_sql)Is this issue gonna be re-open?
brunowego
commented
7 years ago Same issue here...
gem 'omniauth', '~> 1.3.1'
gem 'devise', '~> 4.2.0'
gem 'devise_token_auth', '~> 0.1.39'
gem 'active_model_serializers', '~> 0.10.3'[active_model_serializers] Rendered ActiveModel::Serializer::Null with Hash (0.19ms)Hi @brunowego , I found a workaround in this stackoverflow post . I just added:
serialization_scope :view_context
To the base controller I'm using for my api (for you it might be ApplicationController) and it worked.
This is my ApiController just in case:
class ApiController < ActionController::Base
include DeviseTokenAuth::Concerns::SetUserByToken
protect_from_forgery with: :null_session, only: Proc.new { |c| c.request.format.json? }
serialization_scope :view_context
endI really hope this is helpfull to you.
brunowego
commented
7 years ago Thanks @godinezb.
It's crazy, random problems. Here works after set tokens = nil or confirm the user. I use postman to develop.
godinezb
commented
7 years ago @brunowego I'm using postman as well. I have used devise token auth in two similar projects, with the same gem sets and only in one of them I faces this issue. I'd be lost if I hand't find that stackoverflow post.
brunowego
commented
7 years ago @godinezb perhaps you can answer this question.
dkniffin
commented
7 years ago I'm also running into this issue.
devise_token auth 0.1.40
devise 4.2.0
active_model_serializer 0.10.2The only thing that seems to fix it is downgrading AMS to 0.10.0.rc4
ramonpm
commented
7 years ago Same problem here, and it worked downgrading to 0.10.0.rc4 for me too
FabioRNobrega
commented
2 years ago Hi people I'm current using
# Authentication
gem 'active_model_serializers', '~> 0.10.10'
gem 'devise_token_auth', '~> 1.2'
my application controller
class ApplicationController < ActionController::API
include DeviseTokenAuth::Concerns::SetUserByToken
before_action :configure_permitted_parameters, if: :devise_controller?
protected
def configure_permitted_parameters
devise_parameter_sanitizer.permit(:account_update, keys: %i[name role])
devise_parameter_sanitizer.permit(:sign_up, keys: %i[name role])
end
end
And when trying from the external front get the headers.response the access-token and client didn't come.
For the comments above, this version of devise_token_auth should have been fixed by now. Any permanent solution to this problem?
Logins produce an error with version 0.10.0.rc5 of active_model_serializers. I've also filed an issue there, because I can't figure out where the root cause is.
With version 0.10.0.rc4 ASM is not serializing the response from devise_token_auth, so sign_in succeeds:
With version 0.10.0.rc5 ASM is attempting to serialize the response from devise_token_auth, so sign_in fails:
I'm not sure if the fix will ultimately reside in active_model_serializers or here.
The error & backtrace is:
I do have a serializer for User, but it looks like devise_token_auth isn't using it. The rc5 output at the top of this issue included this line:
[active_model_serializers] Rendered ActiveModel::Serializer::Null with Hash (0.14ms)... TheNullin there seems odd.With rc4, the
client_idis making it into the build_auth_header method. With rc5, it is not (it exists asdefault).I've been trying to trace back that
client_idvalue, but I haven't been successful in finding where it gets unset.Can you provide any insight on when the
client_idvalue would be unset, or the order of methods that are called during sign_in?