-
Notifications
You must be signed in to change notification settings - Fork 197
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
When adding comment, respond 403 if user is not authed #3833
Conversation
I tested this manually, by setting up a Bodhi dev server, authing a client session, then just hand-editing the cache file and changing the auth token in it so it didn't work any more. After that, I could reproduce the bug at will, and confirm that this change solves it, both for an interactive session just using a |
Failures are because there isn't test coverage. I don't really know the test structure well enough to add tests for this, I can't see how in |
@AdamWill you actually can test it, but it is a bit trickier because by default, all of the unit-tests will use the default guest/testing user and you'd find we use htis approach in i.e.
|
Thanks, guy with excellently-chosen name! Yeah, I realized later yesterday it would make sense to just look at tests of other things that require auth and see how those are done. Thanks for going the extra mile for it though. I'll take your test and clean it up and update the PR. |
3727e8a
to
8fb920c
Compare
Since 2e6326e, which removed the code allowing anonymous comments with a captcha, we have effectively been assuming the session is properly authenticated when adding a comment - we look at `request.user` and `request.user.name` for the 'author' and don't do any checks, we just assume they were set. But if we have a cached session that has expired, or something like that, they will *not* be set. Without an explicit check, the error the client ultimately gets when trying to add the comment fails is not one which the client code recognizes as meaning 'reauthentication needed', so the client just sort of bails out. This was breaking apps like fedora-easy-karma which just retrieves a bunch of update info then tries to leave comments, once the cached session for the client expired. To fix this, we'll restore the check (removed in 2e6326e) that `author` actually gets set, and tweak it a bit to return 403 not 400 if it wasn't set. The client code *does* recognize a 403 response as meaning 'reauth needed', so this fixes the problem, and it's a more correct response than 400 anyway. Resolves: fedora-infra#3298 Signed-off-by: Adam Williamson <awilliam@redhat.com>
8fb920c
to
c255cf2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for figuring out that return 403 will force re-auth :-)
Since 2e6326e, which removed the code allowing anonymous
comments with a captcha, we have effectively been assuming the
session is properly authenticated when adding a comment - we
look at
request.user
andrequest.user.name
for the 'author'and don't do any checks, we just assume they were set. But if
we have a cached session that has expired, or something like
that, they will not be set. Without an explicit check, the
error the client ultimately gets when trying to add the comment
fails is not one which the client code recognizes as meaning
'reauthentication needed', so the client just sort of bails out.
This was breaking apps like fedora-easy-karma which just
retrieves a bunch of update info then tries to leave comments,
once the cached session for the client expired.
To fix this, we'll restore the check (removed in 2e6326e) that
author
actually gets set, and tweak it a bit to return 403 not400 if it wasn't set. The client code does recognize a 403
response as meaning 'reauth needed', so this fixes the problem,
and it's a more correct response than 400 anyway.
Resolves: #3298
Signed-off-by: Adam Williamson awilliam@redhat.com