Skip to main content

Security in Integration

Filez Document Platform Authentication​

Frontend Integration Method​

Uses signature (HMAC) for authentication. Filez Document Platform and the business system agree on a secret key and encryption (signature) method. The business system signs the URL for requesting Filez Document Platform's online editing/preview using the agreed secret key. After Filez Document Platform receives the request, it calculates the signature of the request URL using the secret key stored in Filez Document Platform. If it matches the signature passed by the business system, authentication passes. While completing authentication, it also ensures the integrity of the request (prevents tampering).

Standard Integration Method​

For the standard integration method, Filez Document Platform uses delegated authentication. When the business system requests Filez Document Platform's online editing/preview, the Filez Document Platform server calls back the business system's API with the authentication information passed from the business system. If the business system passes the authentication of this API, Filez Document Platform also passes.

There are two cases:

  1. The third-party service and zOffice server are on the same domain.

Through Cookie. The third-party service passes the user's Auth info (such as: sessionId) from the frontend through Cookie. Since the third-party service and zOffice server are on the same domain, requests sent to the zOffice server will automatically include these Cookies.

When zOffice needs to access the third-party service API, it will include all Cookies related to that user.

  1. The third-party service and zOffice server are on different domains

The third party sets the Auth token when calling the zOffice entry API. It can be set in the URL query parameter, such as (?zdocs_access_token=xxxxx).

When zOffice needs to access the third-party service API, it will include the related token in the Cookie (zdocs_access_token=xxxxx).

When using this method, you need to configure the third-party token name in the Document Platform.

Third-Party Verification​

  1. When the third-party system receives a request from zOffice, it must perform corresponding Auth verification.

  2. Since the URL pattern is relatively simple, end users can try to edit/preview other files by modifying the URL. For example: a user is editing

https://oa.mycom.com/docs/app/thirdparty-rest/123/edit/content

They can try to change 123 to 234,

https://oa.mycom.com/docs/app/thirdparty-rest/234/edit/content

to try to edit file 234.

The meta API implemented by the third-party system must verify whether the current requesting user has permission to edit/preview this file (the file requested in meta) and return the correct value. When zOffice edits or previews any file, it will send a meta request to the third-party system to confirm the current user's permissions for this document. The user may be a legitimate user of the system, but they may not have permission to access this file in the third-party system.

During integration, you can pass the third-party system's verification information to the zOffice server by including a token in the edit URL (especially in cross-domain situations). Generally, the token represents the corresponding user. If the editing interface is a separate browser page, users can easily get this URL from the browser's address bar and share it with others.

Starting from v7.1, the Document Platform integration version supports the frontend integration method. When using the frontend integration method, the URL for calling zOffice online editing services needs to include a timestamp. The zOffice service will check the timestamp of the call request to ensure that a call request is only valid for a short period. At the same time, the requester and caller will use the same secret to sign the request to ensure that the request is not tampered with.

Last updated on