You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jan 28, 2022. It is now read-only.
the filter section .filter(scopes__count=num_scopes) incorrectly applies to individual token scope records (which is always 1) vs to the count of actual scopes which is intended. There by only passing the test if testing against a token with a single scope that matches.
The generated SQL (on MySQL at least) for a token with three scopes would look like...
SELECT esi_token.id, esi_token_scopes.scope_id
FROM esi_token
LEFT OUTER JOIN esi_token_scopes ON (esi_token.id = esi_token_scopes.token_id)
INNER JOIN esi_token_scopes T4 ON (esi_token.id = T4.token_id)
INNER JOIN esi_token_scopes T6 ON (esi_token.id = T6.token_id)
INNER JOIN esi_token_scopes T8 ON (esi_token.id = T8.token_id)
WHERE ( esi_token.character_id = 1111111111 AND
T4.scope_id = 3 AND
T6.scope_id = 6 AND
T8.scope_id = 7 )
GROUP BY esi_token.id, esi_token_scopes.scope_id
HAVING COUNT(esi_token_scopes.scope_id) = 3 # <-- issue here
ORDER BY NULL;
the HAVING ... line refers to the count of a single token_id, scope_id pair, for which any token should only have zero or one of any given scope.. so that value would never be greater than 1.
This seems to explain why on AllianceAuth, if the LOGIN_TOKEN_SCOPES has more than one scope , every time a user logs in, the DB ends up with a duplicate token saved. As a test, removing the .filter(scopes__count=num_scopes) part of filter results in the expected behavior.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
the filter section
.filter(scopes__count=num_scopes)
incorrectly applies to individual token scope records (which is always 1) vs to the count of actual scopes which is intended. There by only passing the test if testing against a token with a single scope that matches.The generated SQL (on MySQL at least) for a token with three scopes would look like...
SELECT
esi_token
.id
,esi_token_scopes
.scope_id
FROM
esi_token
LEFT OUTER JOIN
esi_token_scopes
ON (esi_token
.id
=esi_token_scopes
.token_id
)INNER JOIN
esi_token_scopes
T4 ON (esi_token
.id
= T4.token_id
)INNER JOIN
esi_token_scopes
T6 ON (esi_token
.id
= T6.token_id
)INNER JOIN
esi_token_scopes
T8 ON (esi_token
.id
= T8.token_id
)WHERE (
esi_token
.character_id
= 1111111111 ANDT4.
scope_id
= 3 ANDT6.
scope_id
= 6 ANDT8.
scope_id
= 7 )GROUP BY
esi_token
.id
,esi_token_scopes
.scope_id
HAVING COUNT(
esi_token_scopes
.scope_id
) = 3 # <-- issue hereORDER BY NULL;
the HAVING ... line refers to the count of a single token_id, scope_id pair, for which any token should only have zero or one of any given scope.. so that value would never be greater than 1.
This seems to explain why on AllianceAuth, if the LOGIN_TOKEN_SCOPES has more than one scope , every time a user logs in, the DB ends up with a duplicate token saved. As a test, removing the
.filter(scopes__count=num_scopes)
part of filter results in the expected behavior.The text was updated successfully, but these errors were encountered: