-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
not working with latest version of active_model_serializers #600
Comments
I advise you to use active model serializer v0.9 |
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. |
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 They're allowed:
They're just not present. headers for a successful signin request
headers for a failed signin request
I think the key here is that the |
Downgrading to version 0.10.0.rc4 fixes the issue Indicate this in your gemfile: gem 'active_model_serializers', '0.10.0.rc4' |
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! |
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.
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. |
I actually handled it by a little tweak (not the perfect solution though...), but it works for me now with this configuration : |
Method set_user_by_token is called(from current_user) after SessionController create action and @client_id was set to nil.
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! |
Great! Going to close this now. Can re-open if needed. |
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 |
@AbdullahAs +1 |
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:
Is this issue gonna be re-open? |
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:
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:
I really hope this is helpfull to you. |
Thanks @godinezb. It's crazy, random problems. Here works after set |
@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. |
@godinezb perhaps you can answer this question. |
I'm also running into this issue.
The only thing that seems to fix it is downgrading AMS to |
Same problem here, and it worked downgrading to |
Hi people I'm current using
my application controller
And when trying from the external front get the 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)
... TheNull
in there seems odd.With rc4, the
client_id
is 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_id
value, but I haven't been successful in finding where it gets unset.Can you provide any insight on when the
client_id
value would be unset, or the order of methods that are called during sign_in?The text was updated successfully, but these errors were encountered: