- Expédié
- 17 septembre 2026 à 03:33 UTC
- Auteur
- Kamo
- Commite
- cb7395f
GET/api/ai/fournisseurs et GET/api/ai/providers/zuid- répond avec la clé API DECRYPTED de chaque fournisseur. La liste est ce que le picker de modèle de chat AI de chaque membre charge (et kamo-js / l'application mobile), de sorte que n'importe quel membre d'une organisation reorder) n'a besoin que d'une session, de sorte que n'importe quel membre pourrait également pointer l'URL de base d'un fournisseur sur son propre serveur et presser Test, qui envoie la clé déchiffrée là. L'écran de réglages a déjà exigé MANAGE-AI-SETTINGS; Le serveur ne l'a pas fait. - Les deux lectures répondent maintenant aApiKey et a masquéApiKey (les quatre derniers caractères; une clé courte ou non décryptable montre rien de seul). Le masque non utiliséApiKey, qui a masqué le texte chiffré, est remplacé. - Créer, mettre à jour, supprimer, tester et réordonner la réponse 403 sans MANAGE-AI-SETTINGS (God bypasses, comme partout). - La mise à jour conserve la clé stockée à moins qu'une clé non vierge ne soit envoyée. Le formulaire d'édition a été rempli à partir de la clé retournée. une ligne ensemencée en clair (décryptes à "") avait sa clé écrasée avec une blanc chiffrée sur n'importe quelle saveur. AiProviderKeyExposureTest pilote le contrôleur à travers MockMvc avec le vrai SessionHelper: pas de clé dans l'un ou l'autre lire, l'état de la clé signalé, les gardes en blanc / dactylographiés remplacent, et les cinq modifications refusées pour un membre sans la droite avec rien de sauvegardé et aucun adaptateur appelé. Cinq de ses six tests échouent à l'encontre du contrôleur précédent. La forme de réglages kamo-internes cesse d'attendre la clé dans le même ensemble de changement.