Vous ne devez pas créer de route /login dans votre UrlMap : pour une application REST, la méthode Login est appelée implicitement lorsqu’une authentification est requise. Pour ajouter votre traitement, il faut redéfinir Login() dans votre classe qui étend %CSP.REST et appeler le parent avec ##super(skipheader), par exemple : [1][2]

ClassMethod Login(skipheader As %Boolean = 1) As %Status [ ProcedureBlock = 0 ]
{
    // votre journalisation applicative
    Quit ##super(skipheader)
}

Le fait que votre méthode ne soit pas appelée peut venir de la configuration de l’application web REST. Il a été indiqué qu’il faut laisser seulement l’authentification par mot de passe pour cette web application, retirer éventuellement “group by id”, vérifier que UnknownUser n’a pas %ALL, puis tester l’accès ; dans cette configuration, la méthode Login doit être exécutée. Dans votre cas, l’usage du JWT est explicitement mentionné comme différence de configuration. [1][2]

OnPreDispatch n’est pas adapté pour /login, /refresh et /logout : il fonctionne pour vos routes personnalisées, mais pas pour ces routes spéciales. [1][2]

Si vous avez besoin d’un point d’extension fiable autour du login, la piste proposée est d’utiliser une sous-classe de %CSP.SessionEvents, en particulier OnLogin, ou éventuellement OnStartRequest / OnEndRequest selon le besoin de journalisation. [1][2][3]

Sources:

D’après les éléments retrouvés, il n’y a pas d’indication qu’il soit possible de surcharger les méthodes internes standard de connexion comme UsersCSPLogin() ni d’intercepter la requête avant que ce traitement standard ne s’exécute dans le scénario que vous décrivez. Le contenu retrouvé montre au contraire que, lors d’un échec de connexion CSP, la pile passe bien par UsersCSPLogin dans %SYS.SECURITY, puis par CSPLogin dans %SYS.cspServer, ce qui correspond à la validation standard côté serveur que vous observez. [1][2]

Le fait que OnPreHTTP() ne soit jamais appelé pendant ce processus est cohérent avec ce qui est décrit : OnPreHTTP() est un point d’entrée d’une page CSP, invoqué avant l’envoi des en-têtes HTTP pour cette page, et il est typiquement utilisé pour une authentification privée dans une page CSP classique. Mais dans votre cas, le traitement de connexion standard semble se produire avant d’atteindre ce point pour votre page personnalisée. [1][3]

La seule piste concrète proposée dans les documents retrouvés pour obtenir un comportement de « réactivation après 15 minutes » consiste à ne pas essayer de modifier le flux interne de login standard, mais plutôt à mettre en place une tâche personnalisée exécutée périodiquement, par exemple toutes les 15 minutes, afin de réactiver les utilisateurs désactivés. Il est aussi précisé que cette approche serait plus universelle, car il existe d’autres modes de connexion que CSP. [1]

Une autre suggestion mentionnée est de ne pas utiliser l’option Disable account if login limit reached, et éventuellement de jouer uniquement sur Invalid login limit si cela répond au besoin fonctionnel. [1]

Enfin, un autre document rappelle que pour une page de login CSP personnalisée, l’utilisateur du Web Gateway CSPSystem doit avoir les droits de lecture sur la base où se trouve la classe de login personnalisée ; sinon la page personnalisée peut ne pas être chargée correctement et %CSP.Login standard continue d’être utilisée. [4]

En résumé, les documents retrouvés ne donnent pas de mécanisme pour surcharger UsersCSPLogin() ou injecter votre logique juste avant son exécution ; la solution suggérée dans ces sources est plutôt de gérer la réactivation des comptes par une tâche planifiée externe au flux de connexion standard. [1][4][2]

Sources:

L’erreur iris.cls: error finding class indique généralement que le framework IoP n’est pas chargé dans IRIS. Il faut d’abord installer le package Python, puis l’initialiser dans IRIS : pip install iris-pex-embedded-python, puis iop --init ou, en Python, from iop import Utils suivi de Utils.setup(). [1][2][3]

Il faut aussi vérifier que vous êtes dans le bon namespace IRIS via la variable d’environnement IRISNAMESPACE. [1][2]

Pour la migration, la commande documentée est iop --migrate /chemin/absolu/settings.py ou iop -M /tmp/settings.py. Le fichier settings.py doit être dans le même dossier que le code Python, et le chemin doit être absolu. [4][2][5][3]

Votre appel subprocess.run(["iop", "-m", "/external/src/CoreModel/Python/settings.py"], ...) ne correspond pas à la syntaxe montrée dans la documentation récupérée, où -m/-M est l’option de migration et attend le chemin absolu du fichier settings.py. [3]

Le fichier settings.py doit contenir au minimum :

• CLASSES : le mapping des composants Python à enregistrer ;
• PRODUCTIONS : la définition de la production et des items associés. [4][2][6]

Exemple minimal de structure :

from hello_world.bo import MyBo

CLASSES = {
    "MyIRIS.MyBo": MyBo
}

PRODUCTIONS = [
    {
        'MyIRIS.Production': {
            "@TestingEnabled": "true",
            "Item": [
                {
                    "@Name": "Instance.Of.MyBo",
                    "@ClassName": "MyIRIS.MyBo",
                }
            ]
        }
    }
]

[2][6]

Pour enregistrer des composants, la documentation indique aussi ces méthodes alternatives :

• Utils.register_component(...)
• Utils.register_file(...)
• Utils.register_folder(...)
• Utils.migrate() pour migrer le fichier settings.py. [4]

En pratique, l’enchaînement à vérifier est :

1. installer iris-pex-embedded-python ;
2. initialiser IoP dans IRIS avec iop --init ou Utils.setup() ;
3. vérifier IRISNAMESPACE ;
4. utiliser un settings.py valide avec CLASSES et PRODUCTIONS ;
5. lancer la migration avec un chemin absolu, par exemple iop --migrate /external/src/CoreModel/Python/settings.py. [1][4][2][3]

Sources: