Hi Cornelius,
While working with reassign-tokens.py script, I noticed it sometimes produces an error like this (on unassigned token):
Token TOTP00716C3B assigned to rlevytskyi@exadel.com will be migrated to resolver keycloak5 in realm exadel.com.
+-- Assigned token TOTP00716C3B to user <rlevytskyi.keycloak5@exadel.com>.
Traceback (most recent call last):
File "/opt/privacyidea/./reassign-tokens.py", line 63, in <module>
serial, tok.user.login, from_realm, to_resolver, to_realm
^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'login'
With this traceback, it is unclear that error is not about 6C3B token but about next token.
I've added a line to print token-to-be-checked so user has a clue of the failed token, like this:
Checking token TOTP00716C3B ...
Token TOTP00716C3B assigned to rlevytskyi@exadel.com will be migrated to resolver keycloak5 in realm exadel.com.
+-- Assigned token TOTP00716C3B to user <rlevytskyi.keycloak5@exadel.com>.
Checking token TOTP00720AF2 ...
Traceback (most recent call last):
File "/opt/privacyidea/./reassign-tokens.py", line 63, in <module>
serial, tok.user.login, from_realm, to_resolver, to_realm
^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'login'
With this output, it is clear that token in the traceback is 0AF2.
Here's my patch:
--- reassign-tokens.py.old 2026-05-26 16:01:28.946359072 +0300
+++ reassign-tokens.py 2026-05-26 16:02:26.578908310 +0300
@@ -58,6 +58,7 @@
toks = get_tokens(realm=from_realm, resolver=from_resolver)
for tok in toks:
serial = tok.token.serial
+ print("Checking token {0!s} ...".format( serial))
print("Token {0!s} assigned to {1!s}@{2!s} will be migrated to resolver {3!s} in realm {4!s}.".format(
serial, tok.user.login, from_realm, to_resolver, to_realm
))
Hi Cornelius,
While working with reassign-tokens.py script, I noticed it sometimes produces an error like this (on unassigned token):
With this traceback, it is unclear that error is not about 6C3B token but about next token.
I've added a line to print token-to-be-checked so user has a clue of the failed token, like this:
With this output, it is clear that token in the traceback is 0AF2.
Here's my patch: