feat(flex-linux-setup): changes in flex setup to used endpoints for managing admin-ui session #2569
Conversation
…anaging admin-ui session Signed-off-by: Mustafa Baser <mbaser@mail.com>
devrimyatar
added
comp-flex-linux-setup
📝 WalkthroughWalkthroughAdds DB/schema initialization to the Flex installer by integrating RDBMInstaller, a new Changes
Sequence Diagram(s)sequenceDiagram
participant Installer as Flex Installer
participant RDBM as RDBMInstaller
participant DB as Database
participant AdminUI as Admin UI Setup
Installer->>RDBM: load schema_file (flex_schema.json)
Installer->>RDBM: create_tables()
RDBM->>DB: apply schema / create tables
DB-->>RDBM: success/failure
RDBM-->>Installer: result
Installer->>AdminUI: continue install_gluu_admin_ui() (client setup)
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~22 minutes Possibly related PRs
Suggested reviewers
Poem
🚥 Pre-merge checks | ✅ 3 | ❌ 2❌ Failed checks (2 warnings)
✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In @flex-linux-setup/flex_linux_setup/flex_setup.py:
- Line 330: The assigned schema_file path is incorrect: self.schema_file
currently joins self.flex_setup_dir with 'flex_schema.json' but the actual file
lives under the schema subdirectory; update the path construction (the code that
sets self.schema_file) to include the 'schema' directory (e.g., join
self.flex_setup_dir, 'schema', 'flex_schema.json') so the resolved path points
to the real file location.
📜 Review details
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (3)
flex-linux-setup/flex_linux_setup/flex_setup.pyflex-linux-setup/flex_linux_setup/schema/flex_schema.jsonflex-linux-setup/flex_linux_setup/templates/adminUIResourceScopesMapping.ldif
🧰 Additional context used
🧠 Learnings (3)
📚 Learning: 2025-12-25T14:49:29.099Z
Learnt from: duttarnab
Repo: GluuFederation/flex PR: 2540
File: flex-linux-setup/flex_linux_setup/templates/adminUIResourceScopesMapping.ldif:113-113
Timestamp: 2025-12-25T14:49:29.099Z
Learning: In LDIF files under flex-linux-setup/flex_linux_setup/templates, ensure that the assets resource uses the asset.admin scope for DELETE access (instead of asset.delete) so that users with delete access have full read, write, and admin permissions on assets. Apply this convention consistently to similar resources in these templates.
Applied to files:
flex-linux-setup/flex_linux_setup/templates/adminUIResourceScopesMapping.ldif
📚 Learning: 2025-11-11T15:17:34.651Z
Learnt from: devrimyatar
Repo: GluuFederation/flex PR: 2440
File: flex-linux-setup/flex_linux_setup/flex_setup.py:519-519
Timestamp: 2025-11-11T15:17:34.651Z
Learning: In flex-linux-setup/flex_linux_setup/flex_setup.py, the webhook LDIF (aui_webhook.ldif) should only be imported during fresh Admin UI installations, not during updates. The import is correctly guarded by the check `client_check_result['2001.'] == -1` which ensures it only runs when the Admin UI Web Client doesn't already exist. Docker update workflows differ from Linux update workflows in this regard.
Applied to files:
flex-linux-setup/flex_linux_setup/templates/adminUIResourceScopesMapping.ldifflex-linux-setup/flex_linux_setup/flex_setup.py
📚 Learning: 2025-11-11T15:45:04.151Z
Learnt from: devrimyatar
Repo: GluuFederation/flex PR: 2442
File: flex-linux-setup/flex_linux_setup/flex_setup.py:372-374
Timestamp: 2025-11-11T15:45:04.151Z
Learning: In flex-linux-setup/flex_linux_setup/flex_setup.py, the Admin UI policy store JSON file is downloaded from the main branch of the GluuFlexAdminUIPolicyStore repository (https://raw.githubusercontent.com/GluuFederation/GluuFlexAdminUIPolicyStore/refs/heads/main/2fb50e468d9dfefa142d1fce4fa9747efbd3a0f08de5.json). This file is regularly updated, so static checksums are not feasible. The download is handled by base.download() which includes built-in error handling, and JSON validation is performed after download to ensure file integrity before rendering the template.
Applied to files:
flex-linux-setup/flex_linux_setup/flex_setup.py
🔇 Additional comments (6)
flex-linux-setup/flex_linux_setup/schema/flex_schema.json (2)
21-43: LGTM! The adminUISession objectClass definition looks well-structured.The objectClass properly defines the necessary attributes for session management (
sid,jansUjwt,jansUsrDN,creationDate,exp) which align with the PR objectives for managing Admin UI sessions via endpoints.
14-18: PostgreSQL mapping forsql_typesmay be unnecessary if the field is unused.While PostgreSQL is supported by the project (per CHANGELOG), the
sql_typesfield in this schema file does not appear to be referenced or processed by any code in the codebase. Verify whether this metadata field is actually used before adding PostgreSQL mapping.flex-linux-setup/flex_linux_setup/flex_setup.py (3)
274-274: LGTM! RDBMInstaller import and instantiation follow the established pattern.The addition of
RDBMInstallerand its instantiation asrdbm_installerfollows the same pattern used for other installers in this file (e.g.,NodeInstaller,HttpdInstaller,JansInstaller).Also applies to: 307-307
501-502: Placement ofcreate_tables()call is appropriate.Calling
create_tables()before client setup ensures the database schema is initialized before any session-related data operations. The method-level guard suggested earlier will handle non-RDBM backends.
487-491: Remove debug print statement.The debug
Regarding the RDBM backend guard: The proposed pattern
Config.rdbm_installwas not found in the codebase during verification. If a guard is needed, the actual backend detection method used by this installation flow should be identified and applied correctly. Verify whethercreate_tables()should indeed only execute for RDBM backends and what the correct conditional check should be.flex-linux-setup/flex_linux_setup/templates/adminUIResourceScopesMapping.ldif (1)
613-635: Consider addinglogging.writescope for consistency with other resource mappings.Most other resource mappings in this file include the
jansScope: https://jans.io/oauth/jans-auth-server/config/adminui/logging.writescope for audit logging purposes. The newadminUISessionentries are missing this scope.Suggested additions
dn: inum=ae01fe2a-a183-4b71-bc4b-3dfef88d1cd0,ou=adminUIResourceScopesMapping,ou=admin-ui,o=jans inum: ae01fe2a-a183-4b71-bc4b-3dfef88d1cd0 jansAccessType: READ jansResource: adminUISession jansScope: https://jans.io/oauth/jans-auth-server/config/adminui/user/session.readonly +jansScope: https://jans.io/oauth/jans-auth-server/config/adminui/logging.write objectClass: top objectClass: adminUIResourceScopesMapping dn: inum=b954f8d8-86f6-4f3b-ac84-ec8928bbe78f,ou=adminUIResourceScopesMapping,ou=admin-ui,o=jans inum: b954f8d8-86f6-4f3b-ac84-ec8928bbe78f jansAccessType: WRITE jansResource: adminUISession jansScope: https://jans.io/oauth/jans-auth-server/config/adminui/user/session.write +jansScope: https://jans.io/oauth/jans-auth-server/config/adminui/logging.write objectClass: top objectClass: adminUIResourceScopesMapping dn: inum=c954f8d8-6c5f-4d1b-90f6-985dd694d20a,ou=adminUIResourceScopesMapping,ou=admin-ui,o=jans inum: c954f8d8-6c5f-4d1b-90f6-985dd694d20a jansAccessType: DELETE jansResource: adminUISession jansScope: https://jans.io/oauth/jans-auth-server/config/adminui/user/session.delete +jansScope: https://jans.io/oauth/jans-auth-server/config/adminui/logging.write objectClass: top objectClass: adminUIResourceScopesMapping⛔ Skipped due to learnings
Learnt from: duttarnab Repo: GluuFederation/flex PR: 2540 File: flex-linux-setup/flex_linux_setup/templates/adminUIResourceScopesMapping.ldif:113-113 Timestamp: 2025-12-25T14:49:37.060Z Learning: In flex-linux-setup/flex_linux_setup/templates/adminUIResourceScopesMapping.ldif, the assets resource uses `asset.admin` scope for DELETE access type (instead of `asset.delete` like other resources) because users with delete access should automatically have full read, write, and admin permissions on assets.Learnt from: kdhttps Repo: GluuFederation/flex PR: 2378 File: admin-ui/plugins/admin/components/Cedarling/CedarlingConfigPage.tsx:93-104 Timestamp: 2025-11-07T12:55:26.241Z Learning: In the Cedarling configuration feature (admin-ui/plugins/admin/components/Cedarling/CedarlingConfigPage.tsx), the sync role to scopes mappings operation depends on the `auiPolicyStoreUrl`. The backend fetches content from this URL and syncs roles based on the response. Therefore, the audit log for the sync operation should include the `auiPolicyStoreUrl` in its payload to provide proper audit context.
Signed-off-by: Mustafa Baser <mbaser@mail.com>
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In @flex-linux-setup/flex_linux_setup/flex_schema.json:
- Line 10: The schema references an undefined OID macro "flexAttr" for the
attribute's "oid" field while the only defined macro in oidMacros is "jansAttr";
update the "oid" value to use the existing "jansAttr" macro or add a new
"flexAttr" entry to the oidMacros section so the macro names match. Locate the
attribute with "oid": "flexAttr" and either replace it with "jansAttr" (or the
correct existing macro name) or add a corresponding "flexAttr" mapping under
oidMacros so the schema loads successfully.
- Around line 32-34: Remove the redundant "objectclass" entry from the "must"
array in the JSON schema (the array currently contains "objectclass"); edit the
"must" array in flex_schema.json to omit "objectclass" (either remove the key
entirely if allowed or replace with an empty array) so the schema no longer
redundantly lists objectClass as required.
📜 Review details
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
flex-linux-setup/flex_linux_setup/flex_schema.json
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-11-11T15:17:34.651Z
Learnt from: devrimyatar
Repo: GluuFederation/flex PR: 2440
File: flex-linux-setup/flex_linux_setup/flex_setup.py:519-519
Timestamp: 2025-11-11T15:17:34.651Z
Learning: In flex-linux-setup/flex_linux_setup/flex_setup.py, the webhook LDIF (aui_webhook.ldif) should only be imported during fresh Admin UI installations, not during updates. The import is correctly guarded by the check `client_check_result['2001.'] == -1` which ensures it only runs when the Admin UI Web Client doesn't already exist. Docker update workflows differ from Linux update workflows in this regard.
Applied to files:
flex-linux-setup/flex_linux_setup/flex_schema.json
🔇 Additional comments (3)
flex-linux-setup/flex_linux_setup/flex_schema.json (3)
1-48: Schema structure aligns well with Admin UI session management requirements.The schema appropriately defines:
jansUjwtattribute with TEXT storage for potentially large JWTsadminUISessionobject class with relevant session attributes- Directory String syntax suitable for JWT data
- Case-insensitive matching for flexible JWT lookups
This implementation aligns with the PR objectives to store user-info JWTs for Admin UI session management.
24-30: Correct the attribute list - jansUjwt is already defined in this schema file.The
adminUISessionobject class references six attributes in the "may" array:inum,sid,jansUjwt,jansUsrDN,creationDate, andexp. However,jansUjwtis already defined in theattributeTypessection of this file (lines 4-19). The remaining five attributes (inum,sid,jansUsrDN,creationDate,exp) are expected to come from the core Jans schema, which is standard practice for schema extensions. If needed, verify that these five core attributes are available in the Jans schema deployment.Likely an incorrect or invalid review comment.
38-38: Verify that the OID macrojansObjClassis defined in the core Jans schema or resolved at runtime.The object class references
"oid": "jansObjClass", which is not defined in this file'soidMacrossection. Note thatflexAttr(line 10) follows the same pattern. Confirm with the Jans schema maintainers whether these OID macros are:
- Defined in the core Jans schema and resolved during schema loading
- Intended to be defined locally in
oidMacros- Resolved through environment or runtime configuration
If these OIDs are not properly resolved, the schema will fail to load.
Signed-off-by: Mustafa Baser <mbaser@mail.com>
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In @flex-linux-setup/flex_linux_setup/flex_schema.json:
- Around line 32-34: The schema currently only requires "objectclass" which
allows session records without a unique identifier; update the "must" array in
flex_schema.json to include an identifier attribute (e.g., add "inum" or "sid"
alongside "objectclass") so each session has a required unique id, and ensure
the chosen attribute is enforced as unique in your schema/indexing rules if
applicable (reference the "must" array, "objectclass", and the identifier
attribute names "inum" or "sid").
- Line 17: The JSON closing brace on the shown block is indented inconsistently;
adjust the indentation of the closing brace so it aligns with the opening brace
of that object (match indentation used at the opening brace on line 15) to
maintain consistent JSON formatting in flex_schema.json.
📜 Review details
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
flex-linux-setup/flex_linux_setup/flex_schema.json
🧰 Additional context used
🧠 Learnings (1)
📚 Learning: 2025-11-11T15:17:34.651Z
Learnt from: devrimyatar
Repo: GluuFederation/flex PR: 2440
File: flex-linux-setup/flex_linux_setup/flex_setup.py:519-519
Timestamp: 2025-11-11T15:17:34.651Z
Learning: In flex-linux-setup/flex_linux_setup/flex_setup.py, the webhook LDIF (aui_webhook.ldif) should only be imported during fresh Admin UI installations, not during updates. The import is correctly guarded by the check `client_check_result['2001.'] == -1` which ensures it only runs when the Admin UI Web Client doesn't already exist. Docker update workflows differ from Linux update workflows in this regard.
Applied to files:
flex-linux-setup/flex_linux_setup/flex_schema.json
🔇 Additional comments (4)
flex-linux-setup/flex_linux_setup/flex_schema.json (4)
14-18: Add PostgreSQL SQL type mapping to thesql_typesobject.The codebase clearly supports both MySQL and PostgreSQL (as evidenced by docker-flex-monolith configuration files and entrypoint scripts), but the
sql_typesmapping only defines MySQL. Add a"pgsql"entry with the appropriate type mapping (likely"TEXT"to match MySQL).
38-38: No action required; the OID format is correct for this schema.The file uses symbolic string identifiers for OIDs (e.g.,
"jansObjClass","jansPerson") rather than numeric OIDs. This is the intended format for this Jans Flex schema JSON representation. There is nooidMacrossection in the file because the schema doesn't use macro references—it uses direct symbolic identifiers consistently throughout. This format is standard for how Jans represents object classes in this configuration file.Likely an incorrect or invalid review comment.
45-47: OID macroGluuFlexPublishedis not defined in this repository.The
flexAttrmacro maps to"GluuFlexPublished:3", butGluuFlexPublishedis not defined anywhere in the flex codebase. This macro is likely defined in the parent Jans/Janssen schema files that get loaded during deployment viadbUtils.read_jans_schema(). Verify that your Jans installation includes the baseGluuFlexPublishedmacro definition, or ensure it is provided by the parent schema configuration. If the macro is missing from your deployment environment, OID resolution will fail when the schema is loaded.
24-30: Correct the file path and verify attribute definitions against Jans base schema.The file is located at
flex-linux-setup/flex_linux_setup/flex_schema.json(notflex-linux-setup/flex_schema.json). TheadminUISessionobject class references six attributes (inum,sid,jansUjwt,jansUsrDN,creationDate,exp), but onlyjansUjwtis defined in this schema file. Verify that the other five attributes are defined in the base Jans schema and are compatible with this object class.
Signed-off-by: Mustafa Baser <mbaser@mail.com>
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In @flex-linux-setup/flex_linux_setup/flex_schema.json:
- Around line 4-19: The attribute definition for jansUjwt uses caseIgnoreMatch
and caseIgnoreSubstringsMatch which are unsafe for case-sensitive JWT values;
update the schema entry to use caseExactMatch for "equality" and
caseExactSubstringsMatch for "substr" (replace caseIgnoreMatch and
caseIgnoreSubstringsMatch) on the jansUjwt attribute definition, keep the rest
of the object (names, oid, syntax, sql_types) unchanged, and audit any code
paths that log jansUjwt to ensure the attribute value is never logged or
persisted in logs.
- Around line 22-44: The adminUISession objectclass definition currently lists
"sid" in both the "may" and "must" arrays which violates LDAP schema rules; edit
the adminUISession entry in flex_schema.json to remove "sid" from the "may"
array so it only appears in "must", and optionally remove "objectclass" from the
"must" array as it is implicit for all LDAP entries.
📜 Review details
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
flex-linux-setup/flex_linux_setup/flex_schema.json
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: devrimyatar
Repo: GluuFederation/flex PR: 2440
File: flex-linux-setup/flex_linux_setup/flex_setup.py:519-519
Timestamp: 2025-11-11T15:17:34.651Z
Learning: In flex-linux-setup/flex_linux_setup/flex_setup.py, the webhook LDIF (aui_webhook.ldif) should only be imported during fresh Admin UI installations, not during updates. The import is correctly guarded by the check `client_check_result['2001.'] == -1` which ensures it only runs when the Admin UI Web Client doesn't already exist. Docker update workflows differ from Linux update workflows in this regard.
📚 Learning: 2025-11-11T15:17:34.651Z
Learnt from: devrimyatar
Repo: GluuFederation/flex PR: 2440
File: flex-linux-setup/flex_linux_setup/flex_setup.py:519-519
Timestamp: 2025-11-11T15:17:34.651Z
Learning: In flex-linux-setup/flex_linux_setup/flex_setup.py, the webhook LDIF (aui_webhook.ldif) should only be imported during fresh Admin UI installations, not during updates. The import is correctly guarded by the check `client_check_result['2001.'] == -1` which ensures it only runs when the Admin UI Web Client doesn't already exist. Docker update workflows differ from Linux update workflows in this regard.
Applied to files:
flex-linux-setup/flex_linux_setup/flex_schema.json
🔇 Additional comments (2)
flex-linux-setup/flex_linux_setup/flex_schema.json (2)
2-2: EnsureschemaFilenaming/order won’t collide with existing schema load order.If
102-gluu-flex.ldifis loaded alongside other schema files, confirm the numeric prefix and filename are consistent with the installer’s schema ordering rules (and won’t override/duplicate an existing file).
46-48: Verify that generated102-gluu-flex.ldifhas fully-resolved numeric OIDs forjansObjClass.The
flex_schema.jsondefines"oid": "jansObjClass"(line 39) in the objectClass but does not declare this macro locally in theoidMacrossection (which only definesflexAttr). This appears intentional —jansObjClassis expected to resolve from Janssen's core schema during the merge operation performed byread_jans_schema(others=[...]). However, confirm that the generated schema file contains fully-resolved numeric OIDs and imports cleanly.
| { | ||
| "desc": "jansUjwt for flex", | ||
| "equality": "caseIgnoreMatch", | ||
| "names": [ | ||
| "jansUjwt" | ||
| ], | ||
| "oid": "flexAttr", | ||
| "substr": "caseIgnoreSubstringsMatch", | ||
| "syntax": "1.3.6.1.4.1.1466.115.121.1.15", | ||
| "x_origin": "Gluu Flex created attribute", | ||
| "sql_types": { | ||
| "mysql": { | ||
| "type": "TEXT" | ||
| } | ||
| } | ||
| } |
There was a problem hiding this comment.
jansUjwt uses case-insensitive matching, but JWTs are case-sensitive.
If any filter/equality comparison is ever done on jansUjwt, caseIgnoreMatch / caseIgnoreSubstringsMatch can cause false matches. Prefer case-exact matching for JWT strings. Also, storing a user-info JWT can be sensitive; ensure nothing logs this attribute.
Proposed schema tweak (case-exact matching)
"desc": "jansUjwt for flex",
- "equality": "caseIgnoreMatch",
+ "equality": "caseExactMatch",
"names": [
"jansUjwt"
],
"oid": "flexAttr",
- "substr": "caseIgnoreSubstringsMatch",
+ "substr": "caseExactSubstringsMatch",
"syntax": "1.3.6.1.4.1.1466.115.121.1.15",
"x_origin": "Gluu Flex created attribute",📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| { | |
| "desc": "jansUjwt for flex", | |
| "equality": "caseIgnoreMatch", | |
| "names": [ | |
| "jansUjwt" | |
| ], | |
| "oid": "flexAttr", | |
| "substr": "caseIgnoreSubstringsMatch", | |
| "syntax": "1.3.6.1.4.1.1466.115.121.1.15", | |
| "x_origin": "Gluu Flex created attribute", | |
| "sql_types": { | |
| "mysql": { | |
| "type": "TEXT" | |
| } | |
| } | |
| } | |
| { | |
| "desc": "jansUjwt for flex", | |
| "equality": "caseExactMatch", | |
| "names": [ | |
| "jansUjwt" | |
| ], | |
| "oid": "flexAttr", | |
| "substr": "caseExactSubstringsMatch", | |
| "syntax": "1.3.6.1.4.1.1466.115.121.1.15", | |
| "x_origin": "Gluu Flex created attribute", | |
| "sql_types": { | |
| "mysql": { | |
| "type": "TEXT" | |
| } | |
| } | |
| } |
🤖 Prompt for AI Agents
In @flex-linux-setup/flex_linux_setup/flex_schema.json around lines 4 - 19, The
attribute definition for jansUjwt uses caseIgnoreMatch and
caseIgnoreSubstringsMatch which are unsafe for case-sensitive JWT values; update
the schema entry to use caseExactMatch for "equality" and
caseExactSubstringsMatch for "substr" (replace caseIgnoreMatch and
caseIgnoreSubstringsMatch) on the jansUjwt attribute definition, keep the rest
of the object (names, oid, syntax, sql_types) unchanged, and audit any code
paths that log jansUjwt to ensure the attribute value is never logged or
persisted in logs.
Signed-off-by: Mustafa Baser <mbaser@mail.com>
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In @flex-linux-setup/flex_linux_setup/flex_schema.json:
- Around line 21-43: Remove "sid" from the "may" array in the JSON objectclass
definition so it only appears in "must" (attribute: sid) to comply with LDAP
schema rules; update the JSON under the object class entry that currently lists
names: ["adminUISession"], oid: "jansObjClass", and ensure "sid" is removed from
the "may" list. Also verify and, if needed, correct the "objectclass" key to
"objectClass" to match standard LDAP casing used in your LDIF templates and your
schema tooling.
- Around line 45-47: The schema references an OID macro named "jansObjClass" in
objectClasses[0] but oidMacros only defines "flexAttr", causing schema load
failure; add a "jansObjClass" entry to the oidMacros object with the correct OID
string (or replace the "jansObjClass" reference in objectClasses[0] with an
explicit OID), ensuring the symbol "jansObjClass" in oidMacros matches the
identifier used in objectClasses[0] (keep "flexAttr" untouched).
📜 Review details
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
flex-linux-setup/flex_linux_setup/flex_schema.json
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: devrimyatar
Repo: GluuFederation/flex PR: 2440
File: flex-linux-setup/flex_linux_setup/flex_setup.py:519-519
Timestamp: 2025-11-11T15:17:34.651Z
Learning: In flex-linux-setup/flex_linux_setup/flex_setup.py, the webhook LDIF (aui_webhook.ldif) should only be imported during fresh Admin UI installations, not during updates. The import is correctly guarded by the check `client_check_result['2001.'] == -1` which ensures it only runs when the Admin UI Web Client doesn't already exist. Docker update workflows differ from Linux update workflows in this regard.
📚 Learning: 2025-11-11T15:17:34.651Z
Learnt from: devrimyatar
Repo: GluuFederation/flex PR: 2440
File: flex-linux-setup/flex_linux_setup/flex_setup.py:519-519
Timestamp: 2025-11-11T15:17:34.651Z
Learning: In flex-linux-setup/flex_linux_setup/flex_setup.py, the webhook LDIF (aui_webhook.ldif) should only be imported during fresh Admin UI installations, not during updates. The import is correctly guarded by the check `client_check_result['2001.'] == -1` which ensures it only runs when the Admin UI Web Client doesn't already exist. Docker update workflows differ from Linux update workflows in this regard.
Applied to files:
flex-linux-setup/flex_linux_setup/flex_schema.json
🔇 Additional comments (2)
flex-linux-setup/flex_linux_setup/flex_schema.json (2)
2-2: ConfirmschemaFilenaming/ordering is intentional (102-gluu-flex.ldif).
If schema load order matters in your installer, ensure this filename won’t collide with existing schema numbers and that any referenced attributes (e.g.,sid,jansUsrDN, etc.) are already defined by the time this file is applied.
4-18:jansUjwt:caseExactMatchmakes sense for JWTs; verify backend constraints.
JWTs are case-sensitive, socaseExactMatchis reasonable; please verify the directory backend + your schema tooling are happy withsyntax: 1.3.6.1.4.1.1466.115.121.1.15for this payload and that the MySQLTEXTmapping is sufficient for worst-case token sizes in your environment.
| { | ||
| "kind": "STRUCTURAL", | ||
| "may": [ | ||
| "inum", | ||
| "sid", | ||
| "jansUjwt", | ||
| "jansUsrDN", | ||
| "creationDate", | ||
| "exp" | ||
| ], | ||
| "must": [ | ||
| "objectclass", | ||
| "sid" | ||
| ], | ||
| "names": [ | ||
| "adminUISession" | ||
| ], | ||
| "oid": "jansObjClass", | ||
| "sup": [ | ||
| "top" | ||
| ], | ||
| "x_origin": "Gluu Flex created objectclass" | ||
| } |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
find . -name "flex_schema.json" -type fRepository: GluuFederation/flex
Length of output: 115
🏁 Script executed:
wc -l flex-linux-setup/flex_schema.jsonRepository: GluuFederation/flex
Length of output: 127
🏁 Script executed:
wc -l flex-linux-setup/flex_linux_setup/flex_schema.jsonRepository: GluuFederation/flex
Length of output: 116
🏁 Script executed:
head -60 flex-linux-setup/flex_linux_setup/flex_schema.json | cat -nRepository: GluuFederation/flex
Length of output: 1290
🏁 Script executed:
rg -i "schema" --type json | head -20Repository: GluuFederation/flex
Length of output: 2053
🏁 Script executed:
find . -name "*.py" -o -name "*.sh" | xargs rg -l "flex_schema" 2>/dev/null | head -10Repository: GluuFederation/flex
Length of output: 112
🏁 Script executed:
rg -i "objectclass" flex-linux-setup/ -A 2 -B 2Repository: GluuFederation/flex
Length of output: 50375
🏁 Script executed:
cat flex-linux-setup/flex_linux_setup/flex_setup.py | grep -A 20 -B 5 "schema" | head -60Repository: GluuFederation/flex
Length of output: 2635
🏁 Script executed:
find . -name "*.py" | xargs grep -l "objectClass\|objectclass" | head -5Repository: GluuFederation/flex
Length of output: 112
🏁 Script executed:
rg -i "duplicate.*attribute|may.*must|must.*may" --type pyRepository: GluuFederation/flex
Length of output: 45
🏁 Script executed:
rg "read_jans_schema" -A 10 -B 2Repository: GluuFederation/flex
Length of output: 1117
🏁 Script executed:
find . -name "*.py" -type f | xargs grep -l "read_jans_schema" | head -3Repository: GluuFederation/flex
Length of output: 112
🏁 Script executed:
web_searchRepository: GluuFederation/flex
Length of output: 113
🌐 Web query:
LDAP schema attribute in both MAY and MUST redundant invalid
💡 Result:
Short answer: The schema is invalid because the same attribute type is declared as both REQUIRED (MUST) and OPTIONAL (MAY) for the same object class (directly or via inherited superclasses) or the attribute is defined/declared twice with conflicting definitions. LDAP schema rules treat an attribute that appears in both sets as mandatory; conflicting declarations or duplicate attributeType definitions will make the schema fail validation.
How to fix (quick checklist):
- Inspect the objectClass definitions (and their SUP chain) that apply to the entry and find where the attribute appears in MUST and in MAY. Remove it from MAY if it must be required, or remove it from MUST if it should be optional. RFC: an attribute in both sets is considered required. [1]
- Check for duplicate/conflicting attributeType definitions (same short name or OID defined twice) and remove/merge duplicates; ensure each attributeType has a unique, correct OID. [2][3]
- Validate the schema before loading: use slaptest (or your LDAP server’s schema validator) to detect the exact offending schema file/line. For cn=config deployments check cn=schema,cn=config entries; for slapd.conf-style check included .schema files. [2]
- Reload the corrected schema (or update the LDIF in cn=config) and re-run validation.
References:
- RFC 4512 (LDAP models — MUST/MAY and inheritance rules). [1]
- OpenLDAP Administrator Guide (schema and validation guidance). [2]
- Example discussion about duplicate attribute/type and schema errors. [3]
Remove sid from may array — it cannot be in both MAY and MUST.
The same attribute in both MAY and MUST violates LDAP schema standards (RFC 4512). When an attribute is declared in MUST (required), it should not also appear in MAY (optional). Keep sid only in MUST.
Regarding the lowercase objectclass: Standard LDAP uses camelCase (objectClass), as shown in your LDIF templates. Verify with your schema tooling whether the lowercase variant is accepted or if this should be corrected to objectClass.
Proposed fix
"may": [
"inum",
- "sid",
"jansUjwt",
"jansUsrDN",
"creationDate",
"exp"
],📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| { | |
| "kind": "STRUCTURAL", | |
| "may": [ | |
| "inum", | |
| "sid", | |
| "jansUjwt", | |
| "jansUsrDN", | |
| "creationDate", | |
| "exp" | |
| ], | |
| "must": [ | |
| "objectclass", | |
| "sid" | |
| ], | |
| "names": [ | |
| "adminUISession" | |
| ], | |
| "oid": "jansObjClass", | |
| "sup": [ | |
| "top" | |
| ], | |
| "x_origin": "Gluu Flex created objectclass" | |
| } | |
| { | |
| "kind": "STRUCTURAL", | |
| "may": [ | |
| "inum", | |
| "jansUjwt", | |
| "jansUsrDN", | |
| "creationDate", | |
| "exp" | |
| ], | |
| "must": [ | |
| "objectclass", | |
| "sid" | |
| ], | |
| "names": [ | |
| "adminUISession" | |
| ], | |
| "oid": "jansObjClass", | |
| "sup": [ | |
| "top" | |
| ], | |
| "x_origin": "Gluu Flex created objectclass" | |
| } |
🤖 Prompt for AI Agents
In @flex-linux-setup/flex_linux_setup/flex_schema.json around lines 21 - 43,
Remove "sid" from the "may" array in the JSON objectclass definition so it only
appears in "must" (attribute: sid) to comply with LDAP schema rules; update the
JSON under the object class entry that currently lists names:
["adminUISession"], oid: "jansObjClass", and ensure "sid" is removed from the
"may" list. Also verify and, if needed, correct the "objectclass" key to
"objectClass" to match standard LDAP casing used in your LDIF templates and your
schema tooling.
Signed-off-by: Mustafa Baser <mbaser@mail.com>
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Fix all issues with AI agents
In @flex-linux-setup/flex_linux_setup/flex_schema.json:
- Around line 20-42: The schema currently defines the adminUISession object
class but lacks index hints for frequently queried attributes; update the
adminUISession-related attribute definitions (specifically the "sid" and "exp"
attributes) to include appropriate sql_types/index hints similar to the existing
"jansUjwt" attribute definition so the database will create indexes for session
lookup and expiration cleanup; locate the attribute entries for "sid" and "exp"
in the JSON and add the same sql_types/index metadata pattern used by "jansUjwt"
(or add a new sql_types entry specifying an indexed type) to improve query
performance.
- Line 37: The object class OID uses the placeholder "jansObjClass" which is not
defined in oidMacros and is inconsistent with the attribute macro "flexAttr";
fix by either adding a new macro entry in oidMacros (e.g., define "flexObjClass"
with the intended OID like "GluuFlexPublished:4") and update the object class
"oid" to reference that macro, or replace "jansObjClass" directly with the
concrete OID string you want to use (e.g., the full numeric OID). Ensure the
chosen symbol matches usage elsewhere (match "flexAttr"/"flexObjClass") so the
schema is consistent.
📜 Review details
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
flex-linux-setup/flex_linux_setup/flex_schema.json
🧰 Additional context used
🧠 Learnings (2)
📓 Common learnings
Learnt from: devrimyatar
Repo: GluuFederation/flex PR: 2440
File: flex-linux-setup/flex_linux_setup/flex_setup.py:519-519
Timestamp: 2025-11-11T15:17:34.651Z
Learning: In flex-linux-setup/flex_linux_setup/flex_setup.py, the webhook LDIF (aui_webhook.ldif) should only be imported during fresh Admin UI installations, not during updates. The import is correctly guarded by the check `client_check_result['2001.'] == -1` which ensures it only runs when the Admin UI Web Client doesn't already exist. Docker update workflows differ from Linux update workflows in this regard.
📚 Learning: 2025-11-11T15:17:34.651Z
Learnt from: devrimyatar
Repo: GluuFederation/flex PR: 2440
File: flex-linux-setup/flex_linux_setup/flex_setup.py:519-519
Timestamp: 2025-11-11T15:17:34.651Z
Learning: In flex-linux-setup/flex_linux_setup/flex_setup.py, the webhook LDIF (aui_webhook.ldif) should only be imported during fresh Admin UI installations, not during updates. The import is correctly guarded by the check `client_check_result['2001.'] == -1` which ensures it only runs when the Admin UI Web Client doesn't already exist. Docker update workflows differ from Linux update workflows in this regard.
Applied to files:
flex-linux-setup/flex_linux_setup/flex_schema.json
🔇 Additional comments (2)
flex-linux-setup/flex_linux_setup/flex_schema.json (2)
6-6: Correct equality matcher for JWT storage.The use of
caseExactMatchis appropriate for thejansUjwtattribute, as JWTs are case-sensitive. This ensures accurate matching during session lookups.
23-30: No action needed—schema design is correct.The
adminUISessionobject class appropriately references standard Jans attributes (inum,sid,jansUsrDN,creationDate,exp) without redefining them. This file is a schema extension (passed viaothers=parameter toread_jans_schema()) that adds Flex-specific attributes and object classes while leveraging existing base Jans schema elements. This pattern is standard and valid.
Signed-off-by: Mustafa Baser <mbaser@mail.com>
Signed-off-by: Mustafa Baser <mbaser@mail.com>
|
There was a problem hiding this comment.
Actionable comments posted: 1
🤖 Fix all issues with AI agents
In @flex-linux-setup/flex_linux_setup/flex_schema.json:
- Around line 23-30: The schema's attributes lack explicit SQL type mappings;
update the attribute definitions so that inum is mapped to sql_type varchar(64),
sid to sql_type varchar(256), jansUsrDN to sql_type varchar(256), creationDate
to sql_type timestamp, and exp to sql_type timestamp—either add these sql_types
to the existing attributeType entries for inum, sid, jansUsrDN, creationDate,
and exp, or if those attributes are missing from attributeTypes, add new
attributeType objects for each with the specified sql_type values so the RDBM
installer creates correct column types.
📜 Review details
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
📒 Files selected for processing (1)
flex-linux-setup/flex_linux_setup/flex_schema.json
🧰 Additional context used
🧠 Learnings (3)
📓 Common learnings
Learnt from: devrimyatar
Repo: GluuFederation/flex PR: 2440
File: flex-linux-setup/flex_linux_setup/flex_setup.py:519-519
Timestamp: 2025-11-11T15:17:34.651Z
Learning: In flex-linux-setup/flex_linux_setup/flex_setup.py, the webhook LDIF (aui_webhook.ldif) should only be imported during fresh Admin UI installations, not during updates. The import is correctly guarded by the check `client_check_result['2001.'] == -1` which ensures it only runs when the Admin UI Web Client doesn't already exist. Docker update workflows differ from Linux update workflows in this regard.
Learnt from: devrimyatar
Repo: GluuFederation/flex PR: 2569
File: flex-linux-setup/flex_linux_setup/flex_schema.json:37-37
Timestamp: 2026-01-11T12:22:52.015Z
Learning: In the GluuFederation/flex repository, the flex_schema.json file in flex-linux-setup is used to generate SQL tables, not for creating LDAP attributes/objectclasses. OID values in this schema file don't need to follow strict LDAP OID validation rules since they're only used for SQL table generation.
📚 Learning: 2026-01-11T12:22:52.015Z
Learnt from: devrimyatar
Repo: GluuFederation/flex PR: 2569
File: flex-linux-setup/flex_linux_setup/flex_schema.json:37-37
Timestamp: 2026-01-11T12:22:52.015Z
Learning: In flex-linux-setup/flex_linux_setup/flex_schema.json (part of the GluuFederation/flex repo), OID values are used for SQL table generation, not for creating LDAP attributes/objectclasses. Do not enforce strict LDAP OID validation for this schema; treat OIDs as identifiers for SQL-related generation only. Reviewers should focus on SQL-related implications and schema correctness for table generation, not LDAP schema conformance.
Applied to files:
flex-linux-setup/flex_linux_setup/flex_schema.json
📚 Learning: 2025-11-11T15:17:34.651Z
Learnt from: devrimyatar
Repo: GluuFederation/flex PR: 2440
File: flex-linux-setup/flex_linux_setup/flex_setup.py:519-519
Timestamp: 2025-11-11T15:17:34.651Z
Learning: In flex-linux-setup/flex_linux_setup/flex_setup.py, the webhook LDIF (aui_webhook.ldif) should only be imported during fresh Admin UI installations, not during updates. The import is correctly guarded by the check `client_check_result['2001.'] == -1` which ensures it only runs when the Admin UI Web Client doesn't already exist. Docker update workflows differ from Linux update workflows in this regard.
Applied to files:
flex-linux-setup/flex_linux_setup/flex_schema.json
🔇 Additional comments (2)
flex-linux-setup/flex_linux_setup/flex_schema.json (2)
3-18: LGTM: jansUjwt attribute definition is correct.The attribute definition correctly specifies MySQL type as TEXT, matching the requirement from issue #2568.
23-30: Clarify the source of the "PR objectives" requirement about doc_id and dn columns.The review references "PR objectives" specifying doc_id and dn columns, but this requirement document is not found in the repository. Additionally, evidence suggests doc_id is auto-computed from dn via the
doc_id_from_dn()function (found injans.pycloudlib.persistence.sql), and dn is a standard LDAP attribute typically handled implicitly rather than explicitly listed in objectClass definitions.Verify: (1) whether the referenced PR objectives exist in an external issue tracker, and (2) whether the schema design relies on dn being implicitly included as a standard attribute with doc_id derived during persistence operations.
| "may": [ | ||
| "inum", | ||
| "sid", | ||
| "jansUjwt", | ||
| "jansUsrDN", | ||
| "creationDate", | ||
| "exp" | ||
| ], |
There was a problem hiding this comment.
Specify SQL types for all attributes to ensure correct column types.
The attributes inum, sid, jansUsrDN, creationDate, and exp do not have explicit sql_types defined. According to issue #2568:
- inum should be varchar(64)
- sid should be varchar(256)
- jansUsrDN should be varchar(256)
- creationDate should be timestamp
- exp should be timestamp
Without explicit SQL types, the RDBM installer may apply incorrect default types.
📋 Proposed fix to add explicit SQL types
Note: This assumes these attributes are already defined in the Jans schema. If they're not, they need to be added to attributeTypes first. Please verify if inum, sid, jansUsrDN, creationDate, and exp are pre-existing Jans attributes or need to be defined in this schema file.
If they need explicit type definitions in this file, the attributeTypes section should be expanded. Otherwise, ensure the existing definitions in Jans schema have the correct SQL type mappings.
🤖 Prompt for AI Agents
In @flex-linux-setup/flex_linux_setup/flex_schema.json around lines 23 - 30, The
schema's attributes lack explicit SQL type mappings; update the attribute
definitions so that inum is mapped to sql_type varchar(64), sid to sql_type
varchar(256), jansUsrDN to sql_type varchar(256), creationDate to sql_type
timestamp, and exp to sql_type timestamp—either add these sql_types to the
existing attributeType entries for inum, sid, jansUsrDN, creationDate, and exp,
or if those attributes are missing from attributeTypes, add new attributeType
objects for each with the specified sql_type values so the RDBM installer
creates correct column types.
There was a problem hiding this comment.
@coderabbitai if sql data type is not explicitly defined, the following files are used to determine column data types:
https://github.com/JanssenProject/jans/blob/main/jans-linux-setup/jans_setup/static/rdbm/ldap_sql_data_type_mapping.json
https://github.com/JanssenProject/jans/blob/main/jans-linux-setup/jans_setup/static/rdbm/sql_data_types.json
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Fetch the ldap_sql_data_type_mapping.json file
curl -s "https://raw.githubusercontent.com/JanssenProject/jans/main/jans-linux-setup/jans_setup/static/rdbm/ldap_sql_data_type_mapping.json"
Length of output: 1726
🏁 Script executed:
#!/bin/bash
# Fetch the sql_data_types.json file
curl -s "https://raw.githubusercontent.com/JanssenProject/jans/main/jans-linux-setup/jans_setup/static/rdbm/sql_data_types.json"
Length of output: 10309
@devrimyatar, thank you for clarifying the SQL type determination mechanism! I've examined both mapping files and identified some important issues.
While the fallback mechanism works well for most attributes, there are mismatches for the requirements specified in issue #2568:
Analysis of default mappings:
- ✓ inum: If it uses DirectoryString syntax (1.3.6.1.4.1.1466.115.121.1.15), the default VARCHAR(64) matches the requirement
- ✗ sid: If it uses DirectoryString syntax, the default VARCHAR(64) does not match the requirement of VARCHAR(256)
- ✗ jansUsrDN: The default from sql_data_types.json is VARCHAR(128), which does not match the requirement of VARCHAR(256)
- ✓ creationDate: If it uses GeneralizedTime syntax (1.3.6.1.4.1.1466.115.121.1.24), the default TIMESTAMP matches the requirement
- ✓ exp: If it uses GeneralizedTime syntax, the default TIMESTAMP matches the requirement
Recommendation:
You should add explicit sql_types in flex_schema.json for sid and override jansUsrDN to ensure they meet the VARCHAR(256) requirements:
{
"desc": "sid attribute",
"names": ["sid"],
"oid": "...",
"syntax": "...",
"sql_types": {
"mysql": {
"size": 256,
"type": "VARCHAR"
}
}
}Similarly for jansUsrDN, you'd need to override the default to use size 256 instead of 128.
✏️ Learnings added
Learnt from: devrimyatar
Repo: GluuFederation/flex PR: 2569
File: flex-linux-setup/flex_linux_setup/flex_schema.json:23-30
Timestamp: 2026-01-11T16:23:50.540Z
Learning: In GluuFederation/flex repository, when SQL data types are not explicitly defined in schema files like flex_schema.json, the RDBM installer determines column types using two fallback files: ldap_sql_data_type_mapping.json (which maps LDAP syntax OIDs to SQL types) and sql_data_types.json (which maps specific attribute names to SQL types). This fallback mechanism is located in the JanssenProject/jans repository under jans-linux-setup/jans_setup/static/rdbm/.
<!--
Note: Learnings are effective only in the context of similar code segments. To apply general coding guidelines, please configure review instructions. You can manage existing learnings in the app.
🧠 Learnings used
Learnt from: devrimyatar
Repo: GluuFederation/flex PR: 2569
File: flex-linux-setup/flex_linux_setup/flex_schema.json:37-37
Timestamp: 2026-01-11T12:22:52.015Z
Learning: In the GluuFederation/flex repository, the flex_schema.json file in flex-linux-setup is used to generate SQL tables, not for creating LDAP attributes/objectclasses. OID values in this schema file don't need to follow strict LDAP OID validation rules since they're only used for SQL table generation.
Learnt from: devrimyatar
Repo: GluuFederation/flex PR: 2440
File: flex-linux-setup/flex_linux_setup/flex_setup.py:519-519
Timestamp: 2025-11-11T15:17:34.651Z
Learning: In flex-linux-setup/flex_linux_setup/flex_setup.py, the webhook LDIF (aui_webhook.ldif) should only be imported during fresh Admin UI installations, not during updates. The import is correctly guarded by the check `client_check_result['2001.'] == -1` which ensures it only runs when the Admin UI Web Client doesn't already exist. Docker update workflows differ from Linux update workflows in this regard.
There was a problem hiding this comment.
@oderabbitai We updated issue body. Now lenght of sid is 64 characters and dn is 128 characters. Check again.
There was a problem hiding this comment.
Seems like the humans are having a chat. I'll hop back into my burrow for now. If you need me again, just tag @coderabbitai in a new comment, and I'll come hopping out!
There was a problem hiding this comment.
We updated issue body. Now lenght of sid is 64 characters and dn is 128 characters. Check again.
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Fetch the updated issue body for issue #2568
gh issue view 2568 --repo GluuFederation/flex --json body --jq '.body'
Length of output: 40447
@devrimyatar, thank you for the update! I've reviewed the new requirements from issue #2568.
Great news! With the updated column sizes, all attributes now align perfectly with the default SQL type mappings from the fallback mechanism:
Updated Requirements Analysis:
- ✓ inum: varchar(64) - matches DirectoryString default
- ✓ dn: varchar(128) - matches sql_data_types.json mapping
- ✓ sid: varchar(64) - matches DirectoryString default (previously was 256, which would have been a mismatch)
- ✓ jansUsrDN: varchar(128) - matches sql_data_types.json mapping (previously was 256, which would have been a mismatch)
- ✓ creationDate: timestamp - matches GeneralizedTime default
- ✓ exp: timestamp - matches GeneralizedTime default
Conclusion: No explicit sql_types need to be added to flex_schema.json. The RDBM installer will correctly determine all column types using the existing fallback files. The current schema definition is sufficient! ✨
🧠 Learnings used
Learnt from: devrimyatar
Repo: GluuFederation/flex PR: 2569
File: flex-linux-setup/flex_linux_setup/flex_schema.json:37-37
Timestamp: 2026-01-11T12:22:52.015Z
Learning: In the GluuFederation/flex repository, the flex_schema.json file in flex-linux-setup is used to generate SQL tables, not for creating LDAP attributes/objectclasses. OID values in this schema file don't need to follow strict LDAP OID validation rules since they're only used for SQL table generation.
Learnt from: devrimyatar
Repo: GluuFederation/flex PR: 2569
File: flex-linux-setup/flex_linux_setup/flex_schema.json:23-30
Timestamp: 2026-01-11T16:23:50.540Z
Learning: In GluuFederation/flex repository, when SQL data types are not explicitly defined in schema files like flex_schema.json, the RDBM installer determines column types using two fallback files: ldap_sql_data_type_mapping.json (which maps LDAP syntax OIDs to SQL types) and sql_data_types.json (which maps specific attribute names to SQL types). This fallback mechanism is located in the JanssenProject/jans repository under jans-linux-setup/jans_setup/static/rdbm/.
<!--
Learnt from: devrimyatar
Repo: GluuFederation/flex PR: 2440
File: flex-linux-setup/flex_linux_setup/flex_setup.py:519-519
Timestamp: 2025-11-11T15:17:34.651Z
Learning: In flex-linux-setup/flex_linux_setup/flex_setup.py, the webhook LDIF (aui_webhook.ldif) should only be imported during fresh Admin UI installations, not during updates. The import is correctly guarded by the check `client_check_result['2001.'] == -1` which ensures it only runs when the Admin UI Web Client doesn't already exist. Docker update workflows differ from Linux update workflows in this regard.
|
Hi @iromli we also need to implement this in CN installation |
2 participants
Closes #2568
Summary by CodeRabbit
✏️ Tip: You can customize this high-level summary in your review settings.