diff --git a/de/15.10/install/upgrade.rst b/de/15.10/install/upgrade.rst index 96fe8cce6..d0cef8fab 100644 --- a/de/15.10/install/upgrade.rst +++ b/de/15.10/install/upgrade.rst @@ -586,6 +586,8 @@ Bis 15.9 enthielten das Feld ``ip`` des Audit-Protokolls und das Feld ``clientIp Hinter einem Reverse-Proxy, der nicht in ``rate.limit.trusted.proxies`` steht, werden alle Anfragen mit der Adresse des Proxys erfasst. Um die Adresse des ursprünglichen Clients zu erfassen, fügen Sie die Adresse des Proxys zu ``rate.limit.trusted.proxies`` hinzu. +Trägt eine Anfrage von einer Adresse, die nicht in ``rate.limit.trusted.proxies`` steht, ``X-Forwarded-For`` oder ``X-Real-IP``, schreibt 15.10 eine Warnung in ``fess.log``, die die Adresse der Quelle und ``rate.limit.trusted.proxies`` nennt. Die Warnung wird nach dem Start nur einmal geschrieben, nicht für jede Anfrage; sie nennt daher nur die erste solche Adresse und enthält nicht den Wert des Headers. Der Header wird weiterhin ignoriert, sodass sich außer dem Log nichts ändert. Da das Anmeldeformular dieselben Limits verwendet (siehe „Ratenbegrenzung des Anmeldeformulars“ weiter unten), wird jeder Client hinter einem solchen Proxy als eine Adresse gezählt, und sobald die fehlgeschlagenen Anmeldungen das Limit erreichen, werden Anmeldungen von allen abgelehnt. Sehen Sie die Warnung, fügen Sie die Adresse des Proxys zu ``rate.limit.trusted.proxies`` hinzu. + .. _upgrade-1510-cipher-key: Warnung zu ``app.cipher.key`` @@ -600,6 +602,9 @@ Weitere Verhaltensänderungen - „Alle löschen“ in den Bildschirmen „Suche“ und „Crawling-Informationen“ der Administrationsoberfläche erfordert die Bearbeitungsrolle (``admin-searchlist``, ``admin-crawlinginfo``). Bis 15.9 war nur die Schaltfläche ausgeblendet: Anfragen von Benutzern, die nur eine Leserolle (eine Rolle mit der Endung ``-view``) hatten, wurden dennoch angenommen. - Der Zieltext (``output``) eines Eintrags im Zuordnungswörterbuch ist erforderlich. Bis 15.9 nahmen die Administrationsoberfläche und die Administrations-API einen Eintrag ohne ihn an und speicherten nichts. - Bei der Suche trifft ein einzelnes Wort in doppelten Anführungszeichen (etwa ``"less"``) nur auf dieses Wort zu. Bis 15.9 erhielt ein Wort mit mindestens ``query.boost.fuzzy.min.length`` (Standardwert ``4``) Zeichen zusätzlich Bedingungen für unscharfe Treffer, sodass Dokumente mit ``fess`` auch auf ``"less"`` passten. Wörter ohne Anführungszeichen und Wörter mit angegebenem Feld (etwa ``content:"less"``) sind unverändert. +- ``suggest.popular.word.cache.expire`` wird in Sekunden gelesen, wie es ``fess_config.properties`` und :doc:`../config/properties` beschreiben. Bis 15.9 wurde der Wert als Minuten verwendet, sodass der Standardwert ``60`` beliebte Wörter 60 Minuten lang zwischenspeicherte; in 15.10 sind es 60 Sekunden. Um den längeren Cache beizubehalten, setzen Sie einen größeren Wert in Sekunden (``3600`` für 60 Minuten). Der Cache wird außerdem nach jedem Lauf des Suggest-Jobs geleert. +- Der Abruf eines Dokuments über seine Dokument-ID wendet jetzt wie eine Suche den Filter des virtuellen Hosts an. Bis 15.9 wendeten ``/api/v2/cache/{docId}``, die Weiterleitung ``/go/``, Vorschaubilder, die Favoriten-Endpunkte und die übrigen Abrufe über die Dokument-ID nur den Rollenfilter an und antworteten daher bei passenden Rollen auch für ein Dokument eines anderen virtuellen Hosts. In 15.10 gilt ein solches Dokument als nicht gefunden. Wie bei einer Suche wird ein Dokument ohne Wert für den virtuellen Host nicht zurückgegeben, wenn für die Anfrage ein virtueller Host bestimmt wird. Bei einer Anfrage ohne bestimmten virtuellen Host (Standard-Host) ändert sich nichts. +- Der Suggest-Job übernimmt keine Wörter mehr aus Dokumenten, die die Suche ausblendet. Ein Dokument ohne ``role``-Wert und ein Dokument mit einem Verweigerungseintrag (ein Wert, der mit ``role.search.denied.prefix`` (Standardwert ``D``) beginnt und auf den das Präfix eines Benutzers, einer Gruppe oder einer Rolle folgt, standardmäßig also ``D1``, ``D2`` oder ``DR``) werden übersprungen. Bis 15.9 wurden die Wörter solcher Dokumente allen Benutzern vorgeschlagen. Ein Dokument mit Erlaubnis- und Verweigerungseinträgen wird als Ganzes übersprungen, weil eine Suggest-Anfrage keine Verweigerung für einen einzelnen Benutzer ausdrücken kann. Suggest-Einträge, die bereits aus solchen Dokumenten entstanden sind, laufen über die übliche Bereinigung alter Suggest-Daten ab. .. _upgrade-1510-tika: @@ -683,6 +688,41 @@ Steuerzeichen in audit.log Im LTSV-Format wird jedes Steuerzeichen sowie die Unicode-Zeilentrenner NEL, LS und PS in einem Feld durch ein Leerzeichen ersetzt (ein Tabulator durch einen Unterstrich), sodass ein eingegebener Benutzername keinen zweiten Datensatz beginnen kann. 15.9 ersetzte nur CR und LF. +Rollen von Dateien aus ACLs +--------------------------- + +Beim Crawlen eines lokalen Dateisystems (``file:``-URLs), dessen Dateien ACLs haben (etwa NTFS), und mit ``file.role.from.file`` auf dem Standardwert ``true`` machte 15.9 jeden ACL-Eintrag einer Datei zu einer Rolle, die das Dokument lesen darf, unabhängig von Typ und Berechtigungen des Eintrags. Ein Benutzer, dem das Lesen verweigert wurde oder der nur Schreibzugriff erhielt, wurde dadurch zum Leser des indexierten Dokuments. + +15.10 prüft Typ und Berechtigungen jedes Eintrags: + +- Ein ALLOW-Eintrag, der das Lesen von Daten (``READ_DATA``) einschließt, gibt dem Benutzer oder der Gruppe wie bisher die Rolle. +- Ein DENY-Eintrag, der ``READ_DATA`` einschließt, ergibt eine verweigerte Rolle: die Rolle mit vorangestelltem ``role.search.denied.prefix`` (Standardwert ``D``), demselben Präfix, das SMB-Crawls verwenden. Die Suche blendet das Dokument für diesen Benutzer oder diese Gruppe aus. +- AUDIT- und ALARM-Einträge sowie Einträge ohne ``READ_DATA`` werden ignoriert. + +Die aus POSIX-Berechtigungen (Eigentümer und Gruppe) gelesenen Rollen bleiben unverändert. + +Ein Dokument behält die Rollen, mit denen es indexiert wurde, bis es erneut gecrawlt wird. Um die neuen Regeln auf vorhandene Dokumente anzuwenden, führen Sie den Dateicrawl erneut aus. + +LDAP: Organisationseinheiten für Rollen und verschachtelte Gruppen +------------------------------------------------------------------ + +Wenn |Fess| die Berechtigungen eines LDAP-/Active-Directory-Benutzers auflöst (siehe :doc:`../config/ldap-integration`), entscheidet der DN eines Gruppeneintrags, ob er eine Rolle (Berechtigungspräfix ``role.search.role.prefix``, Standardwert ``R``) oder eine Gruppe (``role.search.group.prefix``, Standardwert ``2``) ist. Bis 15.9 war ein Eintrag eine Rolle, wenn sein DN irgendwo den Text ``ou=role`` enthielt; auch ein Eintrag unter ``OU=Roles-Requests`` oder ``OU=RoleOwners`` war daher eine Rolle. + +15.10 zerlegt den DN und behandelt einen Eintrag nur dann als Rolle, wenn eine seiner ``ou``-Komponenten genau ``Role`` oder ``Roles`` lautet (ohne Beachtung der Groß- und Kleinschreibung). Jeder andere Eintrag ist eine Gruppe, ebenso ein Eintrag, dessen DN sich nicht zerlegen lässt. + +Die Einträge unter einer OU wie ``OU=Roles-Requests`` erhalten daher den Berechtigungsnamen einer Gruppe statt den einer Rolle (``2name`` statt ``Rname``), und Dokumente, deren Berechtigungen den alten Namen enthalten, treffen für die Benutzer dieser Gruppen nicht mehr zu. Haben Sie sich auf eine solche OU verlassen, verschieben Sie die Einträge nach ``OU=Role`` oder ``OU=Roles`` oder aktualisieren Sie die Berechtigungseinstellungen, die die alten Namen verwenden, und crawlen (oder indexieren) Sie erneut. + +Ist ``ldap.group.filter`` gesetzt (standardmäßig ist er leer), sucht |Fess| mit diesem Filter die Gruppen, die die Gruppen des Benutzers enthalten (verschachtelte Gruppen). Bis 15.9 wurden die DNs der Gruppen des Benutzers ohne Maskierung in diesen Filter eingesetzt. Ein DN mit einem maskierten Zeichen, etwa dem Komma in ``CN=Sales\, EMEA,...``, passte nicht, sodass die verschachtelten Gruppen einer solchen Gruppe ohne Fehlermeldung fehlten, und ein DN mit für LDAP-Filter besonderen Zeichen veränderte den Filter. 15.10 maskiert die DNs (RFC 4515). Die verschachtelten Gruppen solcher Gruppen werden nun gefunden, sodass die betroffenen Benutzer auch die Berechtigungen dieser Gruppen erhalten. + +Rollen in Anfragen ohne Cipher +------------------------------ + +|Fess| kann die Rollen eines Benutzers aus einem Anfrageparameter, einem Header oder einem Cookie lesen, wenn die Komponente ``roleQueryHelper`` in ``fess.xml`` ``parameterKey``, ``headerKey`` oder ``cookieKey`` setzt. Jeder Wert gilt als verschlüsselt, solange ``encryptedParameterValue``, ``encryptedHeaderValue`` oder ``encryptedCookieValue`` nicht auf ``false`` steht (alle drei haben den Standardwert ``true``). + +Bis 15.9 wurde ein Wert, der verschlüsselt sein sollte, als Klartext gelesen, wenn kein ``cipher`` gesetzt war; jeder Client konnte daher eine Rollenliste senden. 15.10 ignoriert einen solchen Wert und schreibt nach dem Start einmalig eine Warnung in ``fess.log``. Ein Wert, dessen Flag ``false`` ist, wird weiterhin unverändert gelesen, und mit gesetztem ``cipher`` wird ein Wert weiterhin entschlüsselt. + +Setzt Ihr ``roleQueryHelper`` einen der Schlüssel ohne ``cipher``, setzen Sie einen ``cipher`` und senden Sie verschlüsselte Werte, oder setzen Sie das Flag für unverschlüsselt gesendete Werte auf ``false``. In der mitgelieferten ``fess.xml`` sind diese Einstellungen auskommentiert, sodass eine Standardinstallation nicht betroffen ist. + Änderungen für Plugin-Entwickler -------------------------------- diff --git a/en/15.10/install/upgrade.rst b/en/15.10/install/upgrade.rst index 601cbb9ca..60b965608 100644 --- a/en/15.10/install/upgrade.rst +++ b/en/15.10/install/upgrade.rst @@ -572,6 +572,8 @@ Up to 15.9, the ``ip`` field of the audit log and the ``clientIp`` field of the Behind a reverse proxy that is not in ``rate.limit.trusted.proxies``, every request is recorded with the address of the proxy. To record the address of the original client, add the address of the proxy to ``rate.limit.trusted.proxies``. +If a request from an address that is not in ``rate.limit.trusted.proxies`` carries ``X-Forwarded-For`` or ``X-Real-IP``, 15.10 writes a warning to ``fess.log`` that names the address of the source and ``rate.limit.trusted.proxies``. The warning is written once after startup, not for every request, so it names only the first such address, and it does not contain the value of the header. The header is still ignored, so nothing changes except the log. Because the login form uses the same limits (see "Login Form Rate Limit" below), every client behind such a proxy is counted as one address, and once the failed logins reach the limit, logins from all of them are refused. If you see the warning, add the address of the proxy to ``rate.limit.trusted.proxies``. + .. _upgrade-1510-cipher-key: Warning for ``app.cipher.key`` @@ -586,6 +588,9 @@ Other Behavior Changes - "Delete all" in the "Search" and "Crawling Info" screens of the admin UI requires the edit role (``admin-searchlist``, ``admin-crawlinginfo``). Up to 15.9, only the button was hidden: requests from a user who had only a view role (a role with the ``-view`` suffix) were still accepted. - The converted text (``output``) of a mapping dictionary item is required. Up to 15.9, the admin UI and the admin API accepted an item without it and stored nothing. - In a search, a single word in double quotes (such as ``"less"``) matches only that word. Up to 15.9, a word at least ``query.boost.fuzzy.min.length`` (default ``4``) long also got fuzzy match conditions, so documents containing ``fess`` also matched ``"less"``. Unquoted words and words with a field specified (such as ``content:"less"``) are unchanged. +- ``suggest.popular.word.cache.expire`` is read as seconds, as ``fess_config.properties`` and :doc:`../config/properties` describe. Up to 15.9 the value was used as minutes, so the default ``60`` kept popular words cached for 60 minutes; in 15.10 it is 60 seconds. To keep the longer cache, set a larger value in seconds (``3600`` for 60 minutes). The cache is also cleared after every run of the suggest job. +- Looking up a document by its document ID now applies the virtual host filter, as a search does. Up to 15.9, ``/api/v2/cache/{docId}``, the ``/go/`` redirect, thumbnails, the favorite endpoints and the other lookups by document ID applied only the role filter, so when the roles matched they also answered for a document of another virtual host. In 15.10 such a document is treated as not found. As in a search, a document that has no virtual host value is not returned when a virtual host is resolved for the request. Nothing changes for a request with no virtual host resolved (the default host). +- The suggest job no longer takes words from a document that search hides. It skips a document that has no ``role`` value and a document that has a denied entry (a value that starts with ``role.search.denied.prefix`` (default ``D``) followed by the prefix of a user, group or role, that is ``D1``, ``D2`` or ``DR`` by default). Up to 15.9, the words of such documents were suggested to everyone. A document that has both allowed and denied entries is skipped as a whole, because a suggest request cannot express a denial for one user. Suggest entries already created from such documents expire through the usual purge of old suggest data. .. _upgrade-1510-tika: @@ -669,6 +674,41 @@ Control Characters in audit.log In the LTSV format, every control character, and the Unicode line separators NEL, LS and PS, in a field is replaced by a space (a tab by an underscore), so a typed user name cannot start a second record. 15.9 replaced only CR and LF. +Roles of Files Read from ACLs +----------------------------- + +For a crawl of a local file system (``file:`` URLs) whose files have ACLs, such as NTFS, with ``file.role.from.file`` left at the default ``true``, 15.9 turned every ACL entry of a file into a role that may read the document, whatever the type or the permissions of the entry. A user who was denied reading, or who was granted only write access, therefore became a reader of the indexed document. + +15.10 looks at the type and the permissions of each entry: + +- An ALLOW entry that includes read data (``READ_DATA``) gives the user or group the role, as before. +- A DENY entry that includes ``READ_DATA`` gives a denied role: the role with ``role.search.denied.prefix`` (default ``D``) in front of it, the same prefix that SMB crawls use. Search hides the document from that user or group. +- AUDIT and ALARM entries, and entries that do not include ``READ_DATA``, are ignored. + +The roles read from POSIX permissions (owner and group) are unchanged. + +A document keeps the roles it was indexed with until it is crawled again. To apply the new rules to the documents you already have, run the file crawl again. + +LDAP Role Organizational Units and Nested Groups +------------------------------------------------ + +When |Fess| resolves the permissions of an LDAP / Active Directory user (see :doc:`../config/ldap-integration`), the DN of a group entry decides whether it is a role (permission prefix ``role.search.role.prefix``, default ``R``) or a group (``role.search.group.prefix``, default ``2``). Up to 15.9, an entry was a role when its DN contained the text ``ou=role`` anywhere, so an entry under ``OU=Roles-Requests`` or ``OU=RoleOwners`` was a role, too. + +15.10 parses the DN and treats an entry as a role only when one of its ``ou`` components is exactly ``Role`` or ``Roles`` (case-insensitive). Every other entry is a group, and so is an entry whose DN cannot be parsed. + +The entries under an OU such as ``OU=Roles-Requests`` therefore get the permission name of a group instead of that of a role (``2name`` instead of ``Rname``), and documents whose permissions hold the old name no longer match the users of those groups. If you relied on such an OU, move the entries into ``OU=Role`` or ``OU=Roles``, or update the permission settings that use the old names, and crawl (or reindex) again. + +When ``ldap.group.filter`` is set (it is blank by default), |Fess| uses it to look up the groups that contain the groups of the user (nested groups). Up to 15.9, the DNs of the user's groups were put into that filter without escaping. A DN with an escaped character, such as the comma of ``CN=Sales\, EMEA,...``, did not match, so the nested groups of such a group were silently missing, and a DN that contained characters special to LDAP filters changed the filter. 15.10 escapes the DNs (RFC 4515). The nested groups of such groups are now found, so the users concerned get the permissions of those groups, too. + +Roles Sent in a Request Without a Cipher +---------------------------------------- + +|Fess| can read the roles of a user from a request parameter, header or cookie when the ``roleQueryHelper`` component in ``fess.xml`` sets ``parameterKey``, ``headerKey`` or ``cookieKey``. Each value is expected to be encrypted unless ``encryptedParameterValue``, ``encryptedHeaderValue`` or ``encryptedCookieValue`` is set to ``false`` (all three default to ``true``). + +Up to 15.9, a value that was expected to be encrypted was read as plain text when no ``cipher`` was set, so any client could send a role list. 15.10 ignores such a value and writes a warning to ``fess.log`` once after startup. A value whose flag is ``false`` is still read as it is, and a value is still decrypted when a ``cipher`` is set. + +If your ``roleQueryHelper`` sets one of the keys without a ``cipher``, set a ``cipher`` and send encrypted values, or set the flag to ``false`` for the values you send unencrypted. The shipped ``fess.xml`` has these settings commented out, so a default installation is not affected. + Changes for Plugin Developers ----------------------------- diff --git a/es/15.10/install/upgrade.rst b/es/15.10/install/upgrade.rst index d3f734a6f..089e86837 100644 --- a/es/15.10/install/upgrade.rst +++ b/es/15.10/install/upgrade.rst @@ -583,6 +583,8 @@ Hasta 15.9, el campo ``ip`` del registro de auditoría y el campo ``clientIp`` d Detrás de un proxy inverso que no figura en ``rate.limit.trusted.proxies``, todas las solicitudes se guardan con la dirección del proxy. Para guardar la dirección del cliente original, añada la dirección del proxy a ``rate.limit.trusted.proxies``. +Si una solicitud procedente de una dirección que no figura en ``rate.limit.trusted.proxies`` incluye ``X-Forwarded-For`` o ``X-Real-IP``, 15.10 escribe en ``fess.log`` una advertencia que indica la dirección del origen y ``rate.limit.trusted.proxies``. La advertencia se escribe una sola vez después del inicio, no en cada solicitud, por lo que solo indica la primera dirección de este tipo y no contiene el valor de la cabecera. La cabecera se sigue ignorando, de modo que solo cambia el registro. Como el formulario de inicio de sesión usa los mismos límites (consulte «Límite de intentos del formulario de inicio de sesión» más abajo), todos los clientes detrás de un proxy así se cuentan como una sola dirección y, cuando los inicios de sesión fallidos alcanzan el límite, se rechazan los inicios de sesión de todos ellos. Si ve la advertencia, añada la dirección del proxy a ``rate.limit.trusted.proxies``. + .. _upgrade-1510-cipher-key: Advertencia sobre ``app.cipher.key`` @@ -597,6 +599,9 @@ Otros cambios de comportamiento - «Eliminar todo» en las pantallas «Búsqueda» e «Información de rastreo» de la interfaz de administración requiere el rol de edición (``admin-searchlist``, ``admin-crawlinginfo``). Hasta 15.9, solo se ocultaba el botón: las solicitudes de un usuario que solo tenía un rol de visualización (un rol con el sufijo ``-view``) se aceptaban igualmente. - El texto convertido (``output``) de una entrada del diccionario de mapeo es obligatorio. Hasta 15.9, la interfaz de administración y la API de administración aceptaban una entrada sin él y no guardaban nada. - En una búsqueda, una sola palabra entre comillas dobles (como ``"less"``) coincide únicamente con esa palabra. Hasta 15.9, una palabra de al menos ``query.boost.fuzzy.min.length`` (valor predeterminado ``4``) caracteres recibía además condiciones de coincidencia aproximada, de modo que los documentos que contenían ``fess`` también coincidían con ``"less"``. Las palabras sin comillas y las palabras con un campo especificado (como ``content:"less"``) no cambian. +- ``suggest.popular.word.cache.expire`` se lee en segundos, como describen ``fess_config.properties`` y :doc:`../config/properties`. Hasta 15.9 el valor se usaba como minutos, de modo que con el valor predeterminado ``60`` las palabras populares se guardaban en la caché durante 60 minutos; en 15.10 son 60 segundos. Para conservar la caché más larga, defina un valor mayor en segundos (``3600`` para 60 minutos). La caché también se vacía después de cada ejecución del trabajo de sugerencias. +- La búsqueda de un documento por su ID de documento aplica ahora el filtro del host virtual, igual que una búsqueda. Hasta 15.9, ``/api/v2/cache/{docId}``, la redirección ``/go/``, las miniaturas, los puntos de acceso de favoritos y el resto de las búsquedas por ID de documento solo aplicaban el filtro de roles, por lo que, si los roles coincidían, respondían también para un documento de otro host virtual. En 15.10 ese documento se trata como no encontrado. Igual que en una búsqueda, un documento sin valor de host virtual no se devuelve cuando se determina un host virtual para la solicitud. No cambia nada para una solicitud sin host virtual determinado (host predeterminado). +- El trabajo de sugerencias ya no toma palabras de los documentos que la búsqueda oculta. Se omiten un documento sin valor ``role`` y un documento con una entrada denegada (un valor que empieza por ``role.search.denied.prefix`` (valor predeterminado ``D``) seguido del prefijo de un usuario, un grupo o un rol, es decir, por defecto ``D1``, ``D2`` o ``DR``). Hasta 15.9, las palabras de esos documentos se sugerían a todos. Un documento con entradas permitidas y denegadas se omite por completo, porque una solicitud de sugerencias no puede expresar una denegación para un solo usuario. Las entradas de sugerencias ya creadas a partir de esos documentos caducan con la purga habitual de datos antiguos de sugerencias. .. _upgrade-1510-tika: @@ -680,6 +685,41 @@ Caracteres de control en audit.log En el formato LTSV, todo carácter de control de un campo, y los separadores de línea Unicode NEL, LS y PS, se sustituye por un espacio (un tabulador por un guion bajo), de modo que un nombre de usuario escrito no pueda iniciar un segundo registro. La versión 15.9 solo sustituía CR y LF. +Roles de archivos leídos de las ACL +----------------------------------- + +Al rastrear un sistema de archivos local (URL ``file:``) cuyos archivos tienen ACL (por ejemplo, NTFS), con ``file.role.from.file`` en su valor predeterminado ``true``, 15.9 convertía cada entrada de ACL de un archivo en un rol con permiso para leer el documento, sin tener en cuenta el tipo ni los permisos de la entrada. Un usuario al que se había denegado la lectura, o al que solo se había concedido el acceso de escritura, pasaba así a ser lector del documento indexado. + +15.10 examina el tipo y los permisos de cada entrada: + +- Una entrada ALLOW que incluye la lectura de datos (``READ_DATA``) concede el rol al usuario o grupo, como antes. +- Una entrada DENY que incluye ``READ_DATA`` produce un rol denegado: el rol precedido de ``role.search.denied.prefix`` (valor predeterminado ``D``), el mismo prefijo que usan los rastreos SMB. La búsqueda oculta el documento a ese usuario o grupo. +- Las entradas AUDIT y ALARM, y las entradas que no incluyen ``READ_DATA``, se ignoran. + +Los roles leídos de permisos POSIX (propietario y grupo) no cambian. + +Un documento conserva los roles con los que se indexó hasta que se vuelve a rastrear. Para aplicar las nuevas reglas a los documentos existentes, ejecute de nuevo el rastreo de archivos. + +LDAP: unidades organizativas de roles y grupos anidados +------------------------------------------------------- + +Cuando |Fess| resuelve los permisos de un usuario de LDAP / Active Directory (consulte :doc:`../config/ldap-integration`), el DN de una entrada de grupo decide si es un rol (prefijo de permiso ``role.search.role.prefix``, valor predeterminado ``R``) o un grupo (``role.search.group.prefix``, valor predeterminado ``2``). Hasta 15.9, una entrada era un rol cuando su DN contenía el texto ``ou=role`` en cualquier posición; por eso una entrada bajo ``OU=Roles-Requests`` o ``OU=RoleOwners`` también era un rol. + +15.10 analiza el DN y trata una entrada como rol solo cuando uno de sus componentes ``ou`` es exactamente ``Role`` o ``Roles`` (sin distinguir mayúsculas de minúsculas). Cualquier otra entrada es un grupo, igual que una entrada cuyo DN no se puede analizar. + +Por tanto, las entradas bajo una OU como ``OU=Roles-Requests`` reciben el nombre de permiso de un grupo en lugar del de un rol (``2name`` en lugar de ``Rname``), y los documentos cuyos permisos contienen el nombre antiguo dejan de coincidir para los usuarios de esos grupos. Si dependía de una OU así, mueva las entradas a ``OU=Role`` o ``OU=Roles``, o actualice los ajustes de permisos que usan los nombres antiguos, y vuelva a rastrear (o a reindexar). + +Cuando ``ldap.group.filter`` está definido (por defecto está vacío), |Fess| lo usa para buscar los grupos que contienen los grupos del usuario (grupos anidados). Hasta 15.9, los DN de los grupos del usuario se insertaban en ese filtro sin escapar. Un DN con un carácter escapado, como la coma de ``CN=Sales\, EMEA,...``, no coincidía, de modo que los grupos anidados de ese grupo faltaban sin ningún error, y un DN con caracteres especiales de los filtros LDAP modificaba el filtro. 15.10 escapa los DN (RFC 4515). Los grupos anidados de esos grupos ahora se encuentran, por lo que los usuarios afectados obtienen también los permisos de esos grupos. + +Roles enviados en una solicitud sin cipher +------------------------------------------ + +|Fess| puede leer los roles de un usuario de un parámetro, una cabecera o una cookie de la solicitud cuando el componente ``roleQueryHelper`` de ``fess.xml`` define ``parameterKey``, ``headerKey`` o ``cookieKey``. Se espera que cada valor esté cifrado, salvo que ``encryptedParameterValue``, ``encryptedHeaderValue`` o ``encryptedCookieValue`` valga ``false`` (los tres valen ``true`` por defecto). + +Hasta 15.9, un valor que debía estar cifrado se leía como texto sin cifrar cuando no había ``cipher``, de modo que cualquier cliente podía enviar una lista de roles. 15.10 ignora ese valor y escribe una advertencia en ``fess.log`` una sola vez después del inicio. Un valor cuyo indicador es ``false`` se sigue leyendo tal cual, y un valor se sigue descifrando cuando hay un ``cipher``. + +Si su ``roleQueryHelper`` define alguna de las claves sin ``cipher``, defina un ``cipher`` y envíe valores cifrados, o ponga el indicador en ``false`` para los valores que envíe sin cifrar. En el ``fess.xml`` incluido estos ajustes están comentados, por lo que una instalación predeterminada no se ve afectada. + Cambios para desarrolladores de plugins --------------------------------------- diff --git a/fr/15.10/install/upgrade.rst b/fr/15.10/install/upgrade.rst index af45dc2bf..fd8ee75c0 100644 --- a/fr/15.10/install/upgrade.rst +++ b/fr/15.10/install/upgrade.rst @@ -589,6 +589,8 @@ La 15.10 détermine l'adresse selon les mêmes règles que la limitation de déb Derrière un reverse proxy absent de ``rate.limit.trusted.proxies``, toutes les requêtes sont enregistrées avec l'adresse du proxy. Pour enregistrer l'adresse du client d'origine, ajoutez l'adresse du proxy à ``rate.limit.trusted.proxies``. +Si une requête provenant d'une adresse absente de ``rate.limit.trusted.proxies`` contient ``X-Forwarded-For`` ou ``X-Real-IP``, la 15.10 écrit dans ``fess.log`` un avertissement qui indique l'adresse de la source et ``rate.limit.trusted.proxies``. L'avertissement n'est écrit qu'une fois après le démarrage, et non pour chaque requête ; il n'indique donc que la première adresse concernée, et il ne contient pas la valeur de l'en-tête. L'en-tête est toujours ignoré : seul le journal change. Comme le formulaire de connexion utilise les mêmes limites (voir « Limite de tentatives du formulaire de connexion » plus bas), tous les clients derrière un tel proxy sont comptés comme une seule adresse, et dès que les échecs de connexion atteignent la limite, les connexions de tous sont refusées. Si vous voyez cet avertissement, ajoutez l'adresse du proxy à ``rate.limit.trusted.proxies``. + .. _upgrade-1510-cipher-key: Avertissement sur ``app.cipher.key`` @@ -603,6 +605,9 @@ Autres changements de comportement - « Tout supprimer » dans les écrans « Rechercher » et « Informations sur l'exploration » de l'interface d'administration requiert le rôle d'édition (``admin-searchlist``, ``admin-crawlinginfo``). Jusqu'à la 15.9, seul le bouton était masqué : les requêtes d'un utilisateur ne possédant qu'un rôle de consultation (un rôle portant le suffixe ``-view``) étaient tout de même acceptées. - Le texte converti (``output``) d'une entrée du dictionnaire de mappage est obligatoire. Jusqu'à la 15.9, l'interface d'administration et l'API d'administration acceptaient une entrée sans ce champ et n'enregistraient rien. - Dans une recherche, un mot unique entre guillemets doubles (tel que ``"less"``) ne correspond qu'à ce mot. Jusqu'à la 15.9, un mot d'au moins ``query.boost.fuzzy.min.length`` (valeur par défaut ``4``) caractères recevait aussi des conditions de correspondance approximative, de sorte que les documents contenant ``fess`` correspondaient aussi à ``"less"``. Les mots sans guillemets et les mots dont le champ est précisé (tels que ``content:"less"``) ne changent pas. +- ``suggest.popular.word.cache.expire`` est lu en secondes, comme le décrivent ``fess_config.properties`` et :doc:`../config/properties`. Jusqu'à la 15.9, la valeur était utilisée en minutes : avec la valeur par défaut ``60``, les mots populaires restaient en cache 60 minutes ; dans la 15.10, ils y restent 60 secondes. Pour conserver un cache plus long, définissez une valeur plus grande en secondes (``3600`` pour 60 minutes). Le cache est aussi vidé après chaque exécution de la tâche de suggestion. +- La recherche d'un document par son identifiant applique désormais le filtre de l'hôte virtuel, comme une recherche. Jusqu'à la 15.9, ``/api/v2/cache/{docId}``, la redirection ``/go/``, les miniatures, les points d'accès des favoris et les autres recherches par identifiant de document n'appliquaient que le filtre de rôles et répondaient donc, lorsque les rôles correspondaient, pour un document d'un autre hôte virtuel. Dans la 15.10, un tel document est traité comme introuvable. Comme dans une recherche, un document sans valeur d'hôte virtuel n'est pas renvoyé lorsqu'un hôte virtuel est déterminé pour la requête. Rien ne change pour une requête sans hôte virtuel déterminé (hôte par défaut). +- La tâche de suggestion ne prend plus de mots dans les documents que la recherche masque. Un document sans valeur ``role`` et un document avec une entrée refusée (une valeur qui commence par ``role.search.denied.prefix`` (valeur par défaut ``D``) suivi du préfixe d'un utilisateur, d'un groupe ou d'un rôle, soit par défaut ``D1``, ``D2`` ou ``DR``) sont ignorés. Jusqu'à la 15.9, les mots de ces documents étaient suggérés à tout le monde. Un document qui a à la fois des entrées autorisées et refusées est ignoré en entier, car une requête de suggestion ne peut pas exprimer un refus pour un seul utilisateur. Les entrées de suggestion déjà créées à partir de tels documents expirent lors de la purge habituelle des anciennes données de suggestion. .. _upgrade-1510-tika: @@ -686,6 +691,41 @@ Caractères de contrôle dans audit.log Au format LTSV, tout caractère de contrôle d'un champ, ainsi que les séparateurs de ligne Unicode NEL, LS et PS, est remplacé par une espace (une tabulation par un trait de soulignement), de sorte qu'un nom d'utilisateur saisi ne puisse pas commencer un second enregistrement. La version 15.9 ne remplaçait que CR et LF. +Rôles des fichiers lus à partir des ACL +--------------------------------------- + +Lors du crawl d'un système de fichiers local (URL ``file:``) dont les fichiers ont des ACL (NTFS, par exemple), avec ``file.role.from.file`` à sa valeur par défaut ``true``, la 15.9 transformait chaque entrée d'ACL d'un fichier en un rôle autorisé à lire le document, quels que soient le type et les permissions de l'entrée. Un utilisateur auquel la lecture était refusée, ou qui n'avait reçu que l'accès en écriture, devenait donc lecteur du document indexé. + +La 15.10 examine le type et les permissions de chaque entrée : + +- Une entrée ALLOW qui inclut la lecture des données (``READ_DATA``) donne le rôle à l'utilisateur ou au groupe, comme avant. +- Une entrée DENY qui inclut ``READ_DATA`` donne un rôle refusé : le rôle précédé de ``role.search.denied.prefix`` (valeur par défaut ``D``), le même préfixe que celui des crawls SMB. La recherche masque le document pour cet utilisateur ou ce groupe. +- Les entrées AUDIT et ALARM, ainsi que les entrées sans ``READ_DATA``, sont ignorées. + +Les rôles lus à partir des permissions POSIX (propriétaire et groupe) ne changent pas. + +Un document conserve les rôles avec lesquels il a été indexé jusqu'à ce qu'il soit de nouveau crawlé. Pour appliquer les nouvelles règles aux documents existants, relancez le crawl de fichiers. + +LDAP : unités d'organisation des rôles et groupes imbriqués +----------------------------------------------------------- + +Lorsque |Fess| détermine les permissions d'un utilisateur LDAP / Active Directory (voir :doc:`../config/ldap-integration`), le DN d'une entrée de groupe décide s'il s'agit d'un rôle (préfixe de permission ``role.search.role.prefix``, valeur par défaut ``R``) ou d'un groupe (``role.search.group.prefix``, valeur par défaut ``2``). Jusqu'à la 15.9, une entrée était un rôle dès que son DN contenait le texte ``ou=role`` n'importe où ; une entrée sous ``OU=Roles-Requests`` ou ``OU=RoleOwners`` était donc, elle aussi, un rôle. + +La 15.10 analyse le DN et ne traite une entrée comme un rôle que si l'un de ses composants ``ou`` est exactement ``Role`` ou ``Roles`` (sans distinction de casse). Toute autre entrée est un groupe, de même qu'une entrée dont le DN ne peut pas être analysé. + +Les entrées sous une OU telle que ``OU=Roles-Requests`` reçoivent donc le nom de permission d'un groupe au lieu de celui d'un rôle (``2name`` au lieu de ``Rname``), et les documents dont les permissions contiennent l'ancien nom ne correspondent plus aux utilisateurs de ces groupes. Si vous vous appuyiez sur une telle OU, déplacez les entrées dans ``OU=Role`` ou ``OU=Roles``, ou mettez à jour les paramètres de permission qui utilisent les anciens noms, puis relancez un crawl (ou une réindexation). + +Lorsque ``ldap.group.filter`` est défini (il est vide par défaut), |Fess| l'utilise pour rechercher les groupes qui contiennent les groupes de l'utilisateur (groupes imbriqués). Jusqu'à la 15.9, les DN des groupes de l'utilisateur étaient insérés dans ce filtre sans être échappés. Un DN contenant un caractère échappé, comme la virgule de ``CN=Sales\, EMEA,...``, ne correspondait pas : les groupes imbriqués d'un tel groupe manquaient donc sans aucune erreur, et un DN contenant des caractères spéciaux des filtres LDAP modifiait le filtre. La 15.10 échappe les DN (RFC 4515). Les groupes imbriqués de ces groupes sont désormais trouvés, et les utilisateurs concernés obtiennent aussi les permissions de ces groupes. + +Rôles transmis dans une requête sans chiffreur (cipher) +------------------------------------------------------- + +|Fess| peut lire les rôles d'un utilisateur dans un paramètre de requête, un en-tête ou un cookie lorsque le composant ``roleQueryHelper`` de ``fess.xml`` définit ``parameterKey``, ``headerKey`` ou ``cookieKey``. Chaque valeur est supposée chiffrée, sauf si ``encryptedParameterValue``, ``encryptedHeaderValue`` ou ``encryptedCookieValue`` vaut ``false`` (les trois valent ``true`` par défaut). + +Jusqu'à la 15.9, une valeur censée être chiffrée était lue en clair lorsqu'aucun ``cipher`` n'était défini ; n'importe quel client pouvait donc envoyer une liste de rôles. La 15.10 ignore une telle valeur et écrit un avertissement dans ``fess.log``, une seule fois après le démarrage. Une valeur dont l'indicateur vaut ``false`` est toujours lue telle quelle, et une valeur est toujours déchiffrée lorsqu'un ``cipher`` est défini. + +Si votre ``roleQueryHelper`` définit l'une des clés sans ``cipher``, définissez un ``cipher`` et envoyez des valeurs chiffrées, ou mettez l'indicateur à ``false`` pour les valeurs envoyées sans chiffrement. Dans le ``fess.xml`` fourni, ces paramètres sont commentés : une installation par défaut n'est donc pas concernée. + Modifications pour les développeurs de plugins ---------------------------------------------- diff --git a/ja/15.10/install/upgrade.rst b/ja/15.10/install/upgrade.rst index b9b578a05..3513713ad 100644 --- a/ja/15.10/install/upgrade.rst +++ b/ja/15.10/install/upgrade.rst @@ -564,6 +564,8 @@ Docker 版:: ``rate.limit.trusted.proxies`` に含まれないリバースプロキシの背後では、すべてのリクエストがプロキシのアドレスで記録されます。元のクライアントのアドレスを記録するには、プロキシのアドレスを ``rate.limit.trusted.proxies`` に追加してください。 +``rate.limit.trusted.proxies`` に含まれないアドレスから届いたリクエストが ``X-Forwarded-For`` または ``X-Real-IP`` を持っている場合、15.10 は、送信元のアドレスと ``rate.limit.trusted.proxies`` を示す警告を ``fess.log`` へ出力します。警告はリクエストごとではなく起動後に 1 回だけ出力されるため、示されるのは最初に見つかったアドレスだけで、ヘッダーの値は含まれません。ヘッダーは従来どおり無視されるので、ログ以外の動作は変わりません。ログインフォームも同じ制限を使うため（下の「ログインフォームの回数制限」を参照）、このようなプロキシの背後にあるすべてのクライアントは 1 つのアドレスとして数えられ、ログインの失敗が制限に達すると、そのすべてのクライアントのログインが拒否されます。この警告が出た場合は、プロキシのアドレスを ``rate.limit.trusted.proxies`` に追加してください。 + .. _upgrade-1510-cipher-key: ``app.cipher.key`` の警告 @@ -578,6 +580,9 @@ Docker 版:: - 管理画面の「検索リスト」と「クロール情報」の「すべて削除」には、編集ロール（ ``admin-searchlist`` ・ ``admin-crawlinginfo`` ）が必要です。15.9 までは、画面にボタンが表示されないだけで、表示ロール（ ``-view`` が付くロール）だけを持つユーザーのリクエストも受け付けていました。 - マッピング辞書の項目は、変換後（ ``output`` ）が必須です。15.9 までは、省略しても管理画面と管理 API が受け付け、何も保存されませんでした。 - 検索で、ダブルクォーテーションで囲んだ 1 語（ ``"less"`` など）は、その語だけに一致します。15.9 までは、 ``query.boost.fuzzy.min.length`` （既定値は ``4`` ）以上の長さの語に、あいまい一致の条件が加わり、 ``fess`` を含む文書も ``"less"`` に一致していました。引用符のない語と、フィールドを指定した語（ ``content:"less"`` など）は変わりません。 +- ``suggest.popular.word.cache.expire`` は秒として読み込まれます（``fess_config.properties`` と :doc:`../config/properties` の記載どおりです）。15.9 までは値が分として使われていたため、既定値の ``60`` では人気ワードが 60 分間キャッシュされていましたが、15.10 では 60 秒間です。長いキャッシュを維持するには、秒単位でより大きい値（60 分なら ``3600``）を設定してください。キャッシュは、サジェストジョブが実行されるたびにクリアもされます。 +- 文書 ID による文書の取得にも、検索と同じように仮想ホストの絞り込みが適用されます。15.9 までは、``/api/v2/cache/{docId}``、``/go/`` のリダイレクト、サムネイル、お気に入りのエンドポイントなど、文書 ID による取得にはロールの絞り込みだけが適用されていたため、ロールが一致すれば別の仮想ホストの文書にも応答していました。15.10 では、そのような文書は見つからないものとして扱われます。検索と同じく、リクエストで仮想ホストが決まる場合は、仮想ホストの値を持たない文書は返されません。仮想ホストが決まらないリクエスト（既定のホスト）では、動作は変わりません。 +- サジェストジョブは、検索で隠れる文書から語を取り込まなくなりました。``role`` の値を持たない文書と、拒否エントリーを持つ文書（``role.search.denied.prefix``\ （既定は ``D``）の後にユーザー、グループ、ロールのいずれかの接頭辞が続く値。既定では ``D1``、``D2``、``DR``）は、対象外になります。15.9 までは、これらの文書の語がすべてのユーザーにサジェストされていました。許可エントリーと拒否エントリーの両方を持つ文書は、サジェストのリクエストでは特定のユーザーだけを拒否する条件を表せないため、文書全体が対象外になります。すでにこれらの文書から作られたサジェストのエントリーは、サジェストの古いデータを消去する通常の処理で期限切れになります。 .. _upgrade-1510-tika: @@ -659,6 +664,41 @@ Tika 4 がテキストファイルについて報告する文字エンコーデ LTSV 形式では、フィールドの値に含まれるすべての制御文字と、Unicode の行区切り（NEL・LS・PS）が空白に置き換わります（タブはアンダースコア）。入力された利用者名で 2 件目のレコードを始めることはできません。15.9 が置き換えていたのは CR と LF だけでした。 +ACL から読み取るファイルのロール +-------------------------------- + +ACL を持つファイルシステム（NTFS など）上のローカルファイル（``file:`` の URL）をクロールし、``file.role.from.file`` が既定の ``true`` のままの場合、15.9 は、ファイルのすべての ACL エントリーを、エントリーの種類や権限にかかわらず、その文書を読めるロールにしていました。そのため、読み取りを拒否されたユーザーや、書き込みだけを許可されたユーザーも、インデックスされた文書の閲覧者になっていました。 + +15.10 は、各エントリーの種類と権限を確認します。 + +- データの読み取り（``READ_DATA``）を含む ALLOW エントリーは、従来どおり、そのユーザーまたはグループにロールを与えます。 +- ``READ_DATA`` を含む DENY エントリーは、拒否ロール、つまり ``role.search.denied.prefix``\ （既定は ``D``）を前に付けたロールを与えます。SMB クロールが使う接頭辞と同じです。検索では、そのユーザーまたはグループに対して文書が表示されなくなります。 +- AUDIT と ALARM のエントリー、および ``READ_DATA`` を含まないエントリーは無視されます。 + +POSIX 権限（所有者とグループ）から読み取るロールは変わりません。 + +文書は、再度クロールされるまで、インデックスされたときのロールを保持します。すでにある文書に新しい規則を適用するには、ファイルクロールをもう一度実行してください。 + +LDAP のロール OU とネストされたグループ +--------------------------------------- + +|Fess| が LDAP / Active Directory のユーザーの権限を解決するとき（:doc:`../config/ldap-integration` を参照）、グループエントリーの DN によって、そのエントリーがロール（権限の接頭辞は ``role.search.role.prefix``、既定は ``R``）になるか、グループ（``role.search.group.prefix``、既定は ``2``）になるかが決まります。15.9 までは、DN のどこかに ``ou=role`` というテキストが含まれていればロールとして扱われたため、``OU=Roles-Requests`` や ``OU=RoleOwners`` の下のエントリーもロールになっていました。 + +15.10 は DN を解析し、``ou`` の要素のいずれかがちょうど ``Role`` または ``Roles`` である（大文字小文字は区別しません）場合だけ、そのエントリーをロールとして扱います。それ以外のエントリーはすべてグループです。DN を解析できないエントリーもグループです。 + +そのため、``OU=Roles-Requests`` のような OU の下のエントリーは、ロールの権限名ではなくグループの権限名（``Rname`` ではなく ``2name``）になり、古い権限名を持つ文書は、これらのグループのユーザーに一致しなくなります。このような OU を利用していた場合は、エントリーを ``OU=Role`` または ``OU=Roles`` に移すか、古い権限名を使っている権限設定を更新し、もう一度クロール（または再インデックス）してください。 + +``ldap.group.filter`` を設定している場合（既定は空です）、|Fess| はこのフィルターで、ユーザーのグループを含むグループ（ネストされたグループ）を検索します。15.9 までは、ユーザーのグループの DN をエスケープせずにこのフィルターへ入れていました。``CN=Sales\, EMEA,...`` のカンマのようにエスケープされた文字を含む DN には一致しないため、そのグループのネストされたグループはエラーも出ずに取得されず、LDAP フィルターで特別な意味を持つ文字を含む DN はフィルターそのものを変えてしまいました。15.10 は DN をエスケープします（RFC 4515）。そのようなグループのネストされたグループも取得されるようになり、該当するユーザーはそれらのグループの権限も持つようになります。 + +cipher を設定していない場合のリクエストのロール +----------------------------------------------- + +``fess.xml`` の ``roleQueryHelper`` コンポーネントに ``parameterKey``、``headerKey``、``cookieKey`` を設定すると、|Fess| はリクエストのパラメーター、ヘッダー、Cookie からユーザーのロールを読み取ります。値は、``encryptedParameterValue``、``encryptedHeaderValue``、``encryptedCookieValue`` を ``false`` にしない限り、暗号化されていることが前提です（3 つとも既定は ``true`` です）。 + +15.9 までは、暗号化されていることが前提の値でも、``cipher`` が設定されていなければ平文として読み取られたため、どのクライアントでもロールの一覧を送ることができました。15.10 はそのような値を無視し、起動後に 1 回だけ ``fess.log`` へ警告を出力します。フラグが ``false`` の値は従来どおりそのまま読み取られ、``cipher`` が設定されていれば従来どおり復号されます。 + +``roleQueryHelper`` でキーを設定しているのに ``cipher`` を設定していない場合は、``cipher`` を設定して暗号化した値を送るか、暗号化せずに送る値のフラグを ``false`` にしてください。同梱の ``fess.xml`` ではこれらの設定がコメントアウトされているため、既定の構成は影響を受けません。 + プラグイン開発者向けの変更 -------------------------- diff --git a/ko/15.10/install/upgrade.rst b/ko/15.10/install/upgrade.rst index ee009eb1c..1af7114ff 100644 --- a/ko/15.10/install/upgrade.rst +++ b/ko/15.10/install/upgrade.rst @@ -562,6 +562,8 @@ Docker 버전:: ``rate.limit.trusted.proxies`` 에 포함되지 않은 리버스 프록시 뒤에서는 모든 요청이 프록시의 주소로 기록됩니다. 원래 클라이언트의 주소를 기록하려면 프록시의 주소를 ``rate.limit.trusted.proxies`` 에 추가하십시오. +``rate.limit.trusted.proxies`` 에 포함되지 않은 주소에서 온 요청에 ``X-Forwarded-For`` 또는 ``X-Real-IP`` 가 있으면, 15.10은 출처의 주소와 ``rate.limit.trusted.proxies`` 를 알리는 경고를 ``fess.log`` 에 출력합니다. 경고는 요청마다가 아니라 시작 후 한 번만 출력되므로 처음 확인된 주소만 표시되며, 헤더의 값은 포함되지 않습니다. 헤더는 여전히 무시되므로 로그 외에는 달라지는 것이 없습니다. 로그인 폼도 같은 제한을 사용하므로(아래의 「로그인 폼의 횟수 제한」 참조), 이러한 프록시 뒤의 모든 클라이언트는 하나의 주소로 계산되고, 로그인 실패가 제한에 도달하면 이들 모두의 로그인이 거부됩니다. 이 경고가 보이면 프록시의 주소를 ``rate.limit.trusted.proxies`` 에 추가하십시오. + .. _upgrade-1510-cipher-key: ``app.cipher.key`` 경고 @@ -576,6 +578,9 @@ Docker 버전:: - 관리 화면의 「검색」과 「크롤링 정보」의 「모두 삭제」에는 편집 역할(``admin-searchlist``, ``admin-crawlinginfo``)이 필요합니다. 15.9까지는 화면에 버튼이 표시되지 않을 뿐, 열람 역할(``-view`` 가 붙은 역할)만 가진 사용자의 요청도 받아들였습니다. - 매핑 사전 항목은 변환 후 값(``output``)이 필수입니다. 15.9까지는 생략해도 관리 화면과 관리 API가 받아들이고 아무것도 저장하지 않았습니다. - 검색에서 큰따옴표로 묶은 한 단어(``"less"`` 등)는 그 단어에만 일치합니다. 15.9까지는 ``query.boost.fuzzy.min.length`` (기본값 ``4``) 이상 길이의 단어에 퍼지 일치 조건이 추가되어 ``fess`` 를 포함한 문서도 ``"less"`` 에 일치했습니다. 따옴표가 없는 단어와 필드를 지정한 단어(``content:"less"`` 등)는 바뀌지 않습니다. +- ``suggest.popular.word.cache.expire`` 는 ``fess_config.properties`` 와 :doc:`../config/properties` 의 설명대로 초 단위로 읽습니다. 15.9까지는 값이 분 단위로 사용되어 기본값 ``60`` 에서 인기 검색어가 60분 동안 캐시되었지만, 15.10에서는 60초입니다. 이전처럼 오래 캐시하려면 초 단위로 더 큰 값(60분이면 ``3600``)을 설정하십시오. 캐시는 서제스트 잡이 실행될 때마다 비워지기도 합니다. +- 문서 ID로 문서를 가져올 때도 검색과 마찬가지로 가상 호스트 필터가 적용됩니다. 15.9까지는 ``/api/v2/cache/{docId}``, ``/go/`` 리다이렉트, 썸네일, 즐겨찾기 엔드포인트 등 문서 ID로 가져오는 처리에 롤 필터만 적용되어, 롤이 일치하면 다른 가상 호스트의 문서에도 응답했습니다. 15.10에서는 그러한 문서가 없는 것으로 처리됩니다. 검색과 마찬가지로, 요청에서 가상 호스트가 결정되면 가상 호스트 값이 없는 문서는 반환되지 않습니다. 가상 호스트가 결정되지 않는 요청(기본 호스트)에서는 동작이 달라지지 않습니다. +- 서제스트 잡은 검색에서 숨겨지는 문서에서 단어를 가져오지 않습니다. ``role`` 값이 없는 문서와 거부 엔트리가 있는 문서(``role.search.denied.prefix`` (기본값 ``D``) 뒤에 사용자, 그룹, 롤의 접두사가 이어지는 값. 기본적으로 ``D1``, ``D2``, ``DR``)는 건너뜁니다. 15.9까지는 이러한 문서의 단어가 모든 사용자에게 제안되었습니다. 허용 엔트리와 거부 엔트리를 모두 가진 문서는, 서제스트 요청으로는 특정 사용자만 거부하는 조건을 표현할 수 없으므로 문서 전체를 건너뜁니다. 이미 이러한 문서에서 만들어진 서제스트 엔트리는 오래된 서제스트 데이터를 지우는 통상의 처리로 만료됩니다. .. _upgrade-1510-tika: @@ -659,6 +664,41 @@ audit.log의 제어 문자 LTSV 형식에서는 필드 값에 포함된 모든 제어 문자와 유니코드 줄 구분자(NEL, LS, PS)가 공백으로 바뀝니다(탭은 밑줄). 입력된 사용자 이름으로 두 번째 레코드를 시작할 수 없습니다. 15.9가 바꾸던 것은 CR과 LF뿐이었습니다. +ACL에서 읽는 파일의 롤 +---------------------- + +ACL이 있는 파일 시스템(예: NTFS)의 로컬 파일(``file:`` URL)을 크롤링하고 ``file.role.from.file`` 이 기본값 ``true`` 인 경우, 15.9는 파일의 모든 ACL 엔트리를 엔트리의 종류와 권한에 상관없이 그 문서를 읽을 수 있는 롤로 만들었습니다. 그 때문에 읽기가 거부된 사용자나 쓰기만 허용된 사용자도 인덱싱된 문서의 열람자가 되었습니다. + +15.10은 각 엔트리의 종류와 권한을 확인합니다. + +- 데이터 읽기(``READ_DATA``)를 포함하는 ALLOW 엔트리는 종전처럼 해당 사용자나 그룹에 롤을 부여합니다. +- ``READ_DATA`` 를 포함하는 DENY 엔트리는 거부 롤, 즉 롤 앞에 ``role.search.denied.prefix`` (기본값 ``D``)를 붙인 롤을 부여합니다. SMB 크롤링이 사용하는 접두사와 같습니다. 검색에서는 해당 사용자나 그룹에게 문서가 표시되지 않습니다. +- AUDIT와 ALARM 엔트리, 그리고 ``READ_DATA`` 를 포함하지 않는 엔트리는 무시됩니다. + +POSIX 권한(소유자와 그룹)에서 읽는 롤은 달라지지 않습니다. + +문서는 다시 크롤링될 때까지 인덱싱될 때의 롤을 유지합니다. 이미 있는 문서에 새 규칙을 적용하려면 파일 크롤링을 다시 실행하십시오. + +LDAP의 롤 OU와 중첩 그룹 +------------------------ + +|Fess| 가 LDAP / Active Directory 사용자의 권한을 확인할 때(:doc:`../config/ldap-integration` 참조), 그룹 엔트리의 DN에 따라 그 엔트리가 롤(권한 접두사 ``role.search.role.prefix``, 기본값 ``R``)인지 그룹(``role.search.group.prefix``, 기본값 ``2``)인지가 결정됩니다. 15.9까지는 DN의 어느 위치에든 ``ou=role`` 이라는 텍스트가 있으면 롤로 취급했으므로, ``OU=Roles-Requests`` 나 ``OU=RoleOwners`` 아래의 엔트리도 롤이었습니다. + +15.10은 DN을 해석하여, ``ou`` 구성 요소 중 하나가 정확히 ``Role`` 또는 ``Roles`` 인 경우(대소문자 구분 없음)에만 엔트리를 롤로 취급합니다. 그 밖의 엔트리는 모두 그룹이며, DN을 해석할 수 없는 엔트리도 그룹입니다. + +따라서 ``OU=Roles-Requests`` 와 같은 OU 아래의 엔트리는 롤이 아니라 그룹의 권한 이름(``Rname`` 이 아니라 ``2name``)을 갖게 되고, 이전 이름이 권한에 들어 있는 문서는 이들 그룹의 사용자에게 더 이상 일치하지 않습니다. 이러한 OU에 의존하고 있었다면, 엔트리를 ``OU=Role`` 또는 ``OU=Roles`` 로 옮기거나, 이전 이름을 사용하는 권한 설정을 갱신한 뒤 다시 크롤링(또는 재인덱싱)하십시오. + +``ldap.group.filter`` 를 설정한 경우(기본값은 비어 있음), |Fess| 는 이 필터로 사용자의 그룹을 포함하는 그룹(중첩 그룹)을 검색합니다. 15.9까지는 사용자 그룹의 DN을 이스케이프하지 않고 이 필터에 넣었습니다. ``CN=Sales\, EMEA,...`` 의 쉼표처럼 이스케이프된 문자가 있는 DN은 일치하지 않아 그러한 그룹의 중첩 그룹이 오류 없이 누락되었고, LDAP 필터에서 특별한 의미를 갖는 문자가 포함된 DN은 필터를 바꿔 버렸습니다. 15.10은 DN을 이스케이프합니다(RFC 4515). 이러한 그룹의 중첩 그룹도 이제 검색되며, 해당 사용자는 그 그룹의 권한도 갖게 됩니다. + +cipher가 없을 때 요청으로 전달되는 롤 +------------------------------------- + +``fess.xml`` 의 ``roleQueryHelper`` 컴포넌트에 ``parameterKey``, ``headerKey``, ``cookieKey`` 를 설정하면 |Fess| 는 요청의 파라미터, 헤더, 쿠키에서 사용자의 롤을 읽을 수 있습니다. 값은 ``encryptedParameterValue``, ``encryptedHeaderValue``, ``encryptedCookieValue`` 를 ``false`` 로 하지 않는 한 암호화되어 있다고 간주합니다(세 가지 모두 기본값은 ``true``). + +15.9까지는 암호화되어 있어야 하는 값도 ``cipher`` 가 설정되어 있지 않으면 평문으로 읽었으므로, 어떤 클라이언트든 롤 목록을 보낼 수 있었습니다. 15.10은 그러한 값을 무시하고, 시작 후 한 번만 ``fess.log`` 에 경고를 출력합니다. 플래그가 ``false`` 인 값은 종전처럼 그대로 읽으며, ``cipher`` 가 설정되어 있으면 종전처럼 복호화합니다. + +``roleQueryHelper`` 에 키를 설정했는데 ``cipher`` 를 설정하지 않았다면, ``cipher`` 를 설정하고 암호화한 값을 보내거나, 암호화하지 않고 보내는 값의 플래그를 ``false`` 로 하십시오. 기본 제공 ``fess.xml`` 에서는 이 설정들이 주석 처리되어 있으므로 기본 구성은 영향을 받지 않습니다. + 플러그인 개발자를 위한 변경 사항 -------------------------------- diff --git a/zh-cn/15.10/install/upgrade.rst b/zh-cn/15.10/install/upgrade.rst index e1aa05edd..7b2d0ef39 100644 --- a/zh-cn/15.10/install/upgrade.rst +++ b/zh-cn/15.10/install/upgrade.rst @@ -552,6 +552,8 @@ Docker 版:: 在不包含于 ``rate.limit.trusted.proxies`` 的反向代理之后，所有请求都会以代理的地址记录。要记录原始客户端的地址，请将代理的地址添加到 ``rate.limit.trusted.proxies`` 中。 +如果来自不包含在 ``rate.limit.trusted.proxies`` 中的地址的请求带有 ``X-Forwarded-For`` 或 ``X-Real-IP``，15.10 会向 ``fess.log`` 输出一条警告，其中包含来源的地址和 ``rate.limit.trusted.proxies``。该警告在启动后只输出一次，而不是每个请求都输出，因此只会显示第一个这样的地址，并且不包含该请求头的值。该请求头仍会被忽略，所以除日志外没有任何变化。由于登录表单使用相同的限制（参见下文的「登录表单的次数限制」），这类代理之后的所有客户端都会被算作同一个地址，一旦登录失败次数达到限制，这些客户端的登录都会被拒绝。如果看到该警告，请将代理的地址添加到 ``rate.limit.trusted.proxies`` 中。 + .. _upgrade-1510-cipher-key: ``app.cipher.key`` 警告 @@ -566,6 +568,9 @@ Docker 版:: - 管理页面「搜索」和「爬网信息」中的「全部删除」需要编辑角色（``admin-searchlist``、``admin-crawlinginfo``）。直到 15.9，只是页面上不显示按钮，仅拥有查看角色（带有 ``-view`` 的角色）的用户发出的请求也会被接受。 - 映射字典的条目必须填写转换后的值（``output``）。直到 15.9，省略它时管理页面和管理 API 也会接受，并且不保存任何内容。 - 在搜索中，用双引号括起来的单个词（如 ``"less"``）只匹配该词。直到 15.9，长度不少于 ``query.boost.fuzzy.min.length`` （默认值为 ``4``）的词还会附加模糊匹配条件，因此包含 ``fess`` 的文档也会匹配 ``"less"``。不带引号的词和指定了字段的词（如 ``content:"less"``）不变。 +- ``suggest.popular.word.cache.expire`` 按秒读取，与 ``fess_config.properties`` 和 :doc:`../config/properties` 中的说明一致。直到 15.9，该值被当作分钟使用，因此默认值 ``60`` 会让热门词缓存 60 分钟；15.10 中是 60 秒。若要保持更长的缓存，请设置以秒为单位的更大值（60 分钟为 ``3600``）。每次建议作业运行之后，缓存也会被清除。 +- 按文档 ID 获取文档时，现在也会像搜索一样应用虚拟主机过滤。直到 15.9，``/api/v2/cache/{docId}``、``/go/`` 重定向、缩略图、收藏端点以及其他按文档 ID 获取文档的处理只应用角色过滤，因此角色匹配时，也会对属于其他虚拟主机的文档作出响应。15.10 中，这样的文档会被视为不存在。与搜索一样，当请求确定了虚拟主机时，不含虚拟主机值的文档不会被返回。对于没有确定虚拟主机的请求（默认主机），行为不变。 +- 建议作业不再从搜索中被隐藏的文档中获取词语。没有 ``role`` 值的文档，以及带有拒绝条目的文档（值以 ``role.search.denied.prefix``\ （默认值 ``D``）开头，后接用户、组或角色的前缀，默认即 ``D1``、``D2``、``DR``）都会被跳过。直到 15.9，这些文档中的词语会建议给所有用户。同时带有允许条目和拒绝条目的文档会整体跳过，因为建议请求无法表达只拒绝某一个用户。已经从这类文档生成的建议条目，会通过清除旧建议数据的常规处理过期。 .. _upgrade-1510-tika: @@ -647,6 +652,41 @@ audit.log 中的控制字符 在 LTSV 格式中，字段值中的所有控制字符以及 Unicode 行分隔符（NEL、LS、PS）都会被替换为空格（制表符替换为下划线），因此输入的用户名无法开始第二条记录。15.9 只替换 CR 和 LF。 +从 ACL 读取的文件角色 +--------------------- + +在爬取带有 ACL 的文件系统（例如 NTFS）上的本地文件（``file:`` 的 URL），且 ``file.role.from.file`` 保持默认值 ``true`` 时，15.9 会把文件的每个 ACL 条目都变成可以读取该文档的角色，而不管条目的类型和权限。因此，被拒绝读取的用户，或只被授予写入权限的用户，也成为了已建立索引文档的读者。 + +15.10 会检查每个条目的类型和权限： + +- 包含读取数据（``READ_DATA``）的 ALLOW 条目，与之前一样，为该用户或组授予角色。 +- 包含 ``READ_DATA`` 的 DENY 条目会产生拒绝角色，即在角色前加上 ``role.search.denied.prefix``\ （默认值 ``D``），与 SMB 爬取使用的前缀相同。搜索会对该用户或组隐藏该文档。 +- AUDIT 和 ALARM 条目，以及不包含 ``READ_DATA`` 的条目，会被忽略。 + +从 POSIX 权限（所有者和组）读取的角色不变。 + +文档会保留建立索引时的角色，直到再次被爬取。要将新规则应用于已有文档，请再次运行文件爬取。 + +LDAP 的角色 OU 与嵌套组 +----------------------- + +|Fess| 解析 LDAP / Active Directory 用户的权限时（参阅 :doc:`../config/ldap-integration`），组条目的 DN 决定它是角色（权限前缀 ``role.search.role.prefix``，默认值 ``R``）还是组（``role.search.group.prefix``，默认值 ``2``）。直到 15.9，只要 DN 的任意位置包含文本 ``ou=role``，该条目就是角色，因此 ``OU=Roles-Requests`` 或 ``OU=RoleOwners`` 之下的条目也会被当作角色。 + +15.10 会解析 DN，只有当某个 ``ou`` 组成部分恰好是 ``Role`` 或 ``Roles``\ （不区分大小写）时，才把条目当作角色。其他所有条目都是组，无法解析 DN 的条目也是组。 + +因此，``OU=Roles-Requests`` 之类 OU 之下的条目会得到组的权限名称，而不是角色的权限名称（``2name`` 而不是 ``Rname``），权限中包含旧名称的文档将不再匹配这些组的用户。如果依赖这样的 OU，请把条目移到 ``OU=Role`` 或 ``OU=Roles`` 下，或者更新使用旧名称的权限设置，然后重新爬取（或重新建立索引）。 + +设置了 ``ldap.group.filter`` 时（默认为空），|Fess| 会用它查找包含用户所属组的组（嵌套组）。直到 15.9，用户所属组的 DN 是不经转义直接放入该过滤器的。包含转义字符的 DN（例如 ``CN=Sales\, EMEA,...`` 中的逗号）无法匹配，因此这类组的嵌套组会在没有任何错误的情况下缺失；包含 LDAP 过滤器特殊字符的 DN 则会改变过滤器。15.10 会转义 DN（RFC 4515）。这类组的嵌套组现在可以找到，相关用户也会获得这些组的权限。 + +未设置 cipher 时请求中的角色 +---------------------------- + +当 ``fess.xml`` 中的 ``roleQueryHelper`` 组件设置了 ``parameterKey``、``headerKey`` 或 ``cookieKey`` 时，|Fess| 可以从请求参数、请求头或 Cookie 中读取用户的角色。除非将 ``encryptedParameterValue``、``encryptedHeaderValue`` 或 ``encryptedCookieValue`` 设为 ``false``，否则值应为加密状态（三者的默认值都是 ``true``）。 + +直到 15.9，应为加密状态的值在未设置 ``cipher`` 时会被当作明文读取，因此任何客户端都可以发送角色列表。15.10 会忽略这样的值，并在启动后向 ``fess.log`` 输出一次警告。标志为 ``false`` 的值仍按原样读取，设置了 ``cipher`` 时仍会解密。 + +如果 ``roleQueryHelper`` 设置了其中的键却没有设置 ``cipher``，请设置 ``cipher`` 并发送加密后的值，或者对未加密发送的值把标志设为 ``false``。随附的 ``fess.xml`` 中这些设置处于注释状态，因此默认安装不受影响。 + 面向插件开发者的变更 --------------------