Document Generation – /p/ Path Based Access Restriction

0
Hi all,I'm currently setting up the Document Generation module for our Mendix application. Document generation is working correctly in our Acceptance environment, but in Production we receive the following error when attempting to generate a PDF:"DOCGEN_NAVIGATION_ERROR: Failed to navigate to page due to an invalid response code: 403."After enabling Trace logging for DocumentGeneration, we can see that the request to the Document Generation service is successful and returns a 200 response. The callback to /docgen/generate also appears to be successful. However, immediately before the 403 error, the log shows:Using custom URL prefix 'p/'I noticed a difference in the Path Based Access Restrictions between our environments:Acceptance/p/ → N/A (inherit from top level path /)Production/p/ → Deny all accessThe top-level / path in Production is currently set to Allow all access, and /docgen/ is also set to Allow all access.It therefore looks like the /p/ restriction in Production may be preventing Document Generation from navigating to the page it needs to render.Would it be safe/recommended to change /p/ in Production from Deny all access to N/A (inherit from top level path /) to allow Document Generation to work?I'm particularly interested in understanding whether changing this setting introduces any security implications or exposes functionality that would otherwise be inaccessible.
asked
2 answers
0

Hi Nathan,


Yes, the /p/ restriction is relevant here, but I would not change it to Allow all access without first checking what is causing the 403.


The important clue is:

DOCGEN_NAVIGATION_ERROR
Failed to navigate to page due to an invalid response code: 403

The Document Generation service needs to access the page URL that you configured for PDF generation. If that page is exposed through the /p/ path and the environment's Path Based Access Restriction denies access to /p/, the DocGen service can receive a 403 before it can render the page. Mendix documents this as a possible cause of DOCGEN_NAVIGATION_ERROR.


So the difference between your environments is significant:

Acceptance
/p/ → N/A (inherits top-level setting)

Production
/p/ → Deny all access

If the Production top-level restriction is also restrictive, /p/ will effectively block the page request from the Document Generation service.


I would test this in the following order:

  1. Temporarily change the /p/ restriction in Production to Allow all access.
  2. Generate the same PDF again.
  3. If the PDF is generated successfully, you have confirmed that the /p/ access restriction was causing the 403.
  4. Then replace Allow all access with a more restrictive access profile, if your security requirements allow it.

I would not leave /p/ as Allow all access just because it fixes the PDF generation. /p/ contains page/microflow URLs, so exposing it broadly may give more access than you actually want.

Also make sure /docgen/ is accessible. Mendix's current Document Generation configuration specifically requires the /docgen/ path to be accessible for applications deployed on Mendix on Kubernetes Connected.


There is another useful check: open the generated page URL manually with the same application/environment and verify that the page itself can be reached. Mendix recommends temporarily making the page microflow accessible through navigation/button to verify that the page loads correctly and that the configured document user has the required access rights.

So I would look at it as:

Document Generation Service
          |
          v
       /docgen/
          |
          v
   Application / page URL
          |
          v
         /p/
          |
     Path restriction
          |
     +----+----+
     |         |
   Allow     Deny
     |         |
  Render PDF   403

One important distinction: if you are using Mendix Cloud/Dedicated, the /docgen/ request-handler configuration is slightly different from Mendix on Kubernetes Connected. For Kubernetes Connected, Mendix specifically says to make /docgen/ accessible.


So, in your case, I would first use the /p/ → Allow all access change only as a diagnostic test. If that makes PDF generation work, then tighten the restriction rather than leaving the entire /p/ path publicly accessible.


Hope this helps.

answered
0

I'd be careful about treating /p/ → Deny all access as the root cause just because Acceptance and Production differ.

The log entry "Using custom URL prefix 'p/'" definitely makes /p/ worth investigating, but the important question is which page is Document Generation trying to render and under which user context?

Before changing path restrictions, I'd verify that the page configured for document generation can actually be opened by the document generation user and that all data used by the page is accessible to that user.

In my experience, a 403 during DocGen is often caused by page access, entity access, or microflow access rather than the Document Generation callback itself. The callback succeeding only tells you the generation request was accepted.

As a quick test, try opening the exact page URL being rendered. If that page cannot be reached under the same security context, DocGen will fail with the same type of navigation error.

If changing /p/ from Deny all access to N/A makes the issue disappear, that confirms the restriction is involved. In that case I'd compare the Production path-based access configuration with Acceptance and understand why /p/ was explicitly denied before leaving the change in place.

Personally, I would use N/A (inherit) rather than Allow all access unless there is a specific reason to expose the entire /p/ path publicly.


answered