Fix values check in extra_data #891
Conversation
WalkthroughThe update primarily enhances the resilience and flexibility in fetching additional data within the authentication backend. By refining the method to retrieve data, it introduces a more robust approach to handle potential variations in the data source, ensuring that the necessary information is accessible even with different fallback mechanisms. Changes
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
| @@ -146,7 +146,7 @@ def extra_data(self, user, uid, response, details=None, *args, **kwargs): | |||
| elif size == 1: | |||
| name = alias = entry[0] | |||
| discard = False | |||
| value = response.get(name) or details.get(name) or details.get(alias) | |||
| value = response.get(name, details.get(name, details.get(alias))) | |||
There was a problem hiding this comment.
The change in the assignment of value using a nested get method call is intended to fix the bug related to handling integer values in extra_data. However, there's a potential issue with the current implementation:
value = response.get(name, details.get(name, details.get(alias)))This line attempts to address the bug by using a fallback mechanism for retrieving data. However, the use of details.get(name, details.get(alias)) as the default value in the first get call might not be entirely correct. This approach assumes that details will always have the name or alias keys, which might not be the case, potentially leading to None being assigned to value even when response has a relevant entry.
A more robust solution would be to explicitly check for the presence of keys in response and details and then decide the value of value. This could involve a conditional check or a more nuanced approach to ensure that integer values like 0 are correctly handled and not overridden by None or missed due to the fallback logic not being triggered as expected.
There was a problem hiding this comment.
Yep, in the end value can be None, its ok and handled in one line below.
There was a problem hiding this comment.
@igorgaming: Thank you for your patience. After reviewing the lines immediately following the modification, it's clear that the code does indeed handle cases where value might be None. The conditional check:
if discard and not value:
continueensures that if discard is True and value is None (or evaluates to False, which includes 0, False, [], etc.), the loop will continue without assigning None to data[alias]. This mechanism effectively addresses the concern about None values being incorrectly processed, aligning with your explanation. It seems the implementation is designed to accommodate None values appropriately, confirming the robustness of the bug fix. Thank you for clarifying this aspect of the code change.
Analysis chain
Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Extract the lines immediately following the modified line to understand how `None` values are handled.
sed -n '148,160p' social_core/backends/base.py
Length of output: 697
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #891 +/- ##
=======================================
Coverage 77.77% 77.77%
=======================================
Files 347 347
Lines 10606 10606
Branches 699 699
=======================================
Hits 8249 8249
Misses 2200 2200
Partials 157 157
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
|
Merged, thanks for your contribution! |
Proposed changes
Currently, there is a bug in getting extra_data from OAuth providers. For example, if a field from the OAuth API in the
extra_datamethod returns integers (such as 1 or 0), then this will not work correctly and save an incorrect value (in my casenullinstead of0):So this can be fixed like that
{'test': 0}.get('test', 'other expression')Types of changes
Please check the type of change your PR introduces:
Checklist
Put an
xin the boxes that apply. You can also fill these out after creatingthe PR. If you're unsure about any of them, don't hesitate to ask. We're here to
help! This is simply a reminder of what we are going to look for before merging
your code.
Summary by CodeRabbit