# Issues with Permitted Paths - Wrong request designs

**URL:** <https://forum.pritunl.com/t/issues-with-permitted-paths-wrong-request-designs/1410>\
**Category:** Pritunl Zero\
**Created:** [September 27, 2023, 6:28am UTC](https://forum.pritunl.com/t/issues-with-permitted-paths-wrong-request-designs/1410 "2023-09-27T06:28:01Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![karawedi](https://forum.pritunl.com/user_avatar/forum.pritunl.com/karawedi/32/594_2.png) [@karawedi](https://forum.pritunl.com/u/karawedi)\
**Post date:** [September 27, 2023, 6:28am UTC](https://forum.pritunl.com/t/issues-with-permitted-paths-wrong-request-designs/1410/1 "2023-09-27T06:28:01Z")

</div>

Hello everyone!  
I’m currently experimenting with the Permitted Paths option of Pritunl Zero.

I found a major issue, completely destroying the experience and wonder wether this is a misconfiguration on my side or a design decision:

When using permitted Paths, requests allowed by it (everything addressed to a permitted path) will be built differently than the requests issued by a regular, authenticated user.

One quick example: I’m running Nextcloud behind Pritunl Zero. The Moment i add the nextcloud sharing paths to permitted paths, the URLs returned by nextcloud (i.e. hrefs for Buttons, etc.) will change to the internal IP, pritunl used to acces the service, but not the public Domain. This will make the site unusable. Also: Nextcloud will no longer recognize the requests as issued by a reverse Proxy (which would mean, that you set the trusted\_proxy to the pritunl-zero host and the trusted\_domains option to the public DNS), but instead interpret it as a direct request issued by nextcloud (recognized Domain is no longer DNS, but instead the internal IP). Nextcloud behaves correct when permitted paths are unset.

Am I the only one having this issue or is this known?

Thanks in advance you guys!

---

<div class="post-metadata">

**Author:** ![zach](https://forum.pritunl.com/user_avatar/forum.pritunl.com/zach/32/1105_2.png) [@zach](https://forum.pritunl.com/u/zach)\
**Post date:** [September 29, 2023, 3:10pm UTC](https://forum.pritunl.com/t/issues-with-permitted-paths-wrong-request-designs/1410/2 "2023-09-29T15:10:45Z")

</div>

Set the Host option on the right side of the External Domains to the domain of the service.

---

<div class="post-metadata">

**Author:** ![karawedi](https://forum.pritunl.com/user_avatar/forum.pritunl.com/karawedi/32/594_2.png) [@karawedi](https://forum.pritunl.com/u/karawedi)\
**Post date:** [September 30, 2023, 9:57am UTC](https://forum.pritunl.com/t/issues-with-permitted-paths-wrong-request-designs/1410/3 "2023-09-30T09:57:13Z")

</div>

Hi Zach, I’m afraid this did not change the behavior. I’ve already tried that multiple times. Or maybe you misunderstood my message.

---

<div class="post-metadata">

**Author:** ![zach](https://forum.pritunl.com/user_avatar/forum.pritunl.com/zach/32/1105_2.png) [@zach](https://forum.pritunl.com/u/zach)\
**Post date:** [October 3, 2023, 1:27am UTC](https://forum.pritunl.com/t/issues-with-permitted-paths-wrong-request-designs/1410/4 "2023-10-03T01:27:17Z")

</div>

I will need more information about the requests. There is a different mechanism used for permitted paths. This is referenced as `webisolated` in the code [**pritunl-zero/proxy/webisolated.go**](https://github.com/pritunl/pritunl-zero/blob/master/proxy/webisolated.go). For improved safety requests for permitted paths are more restricted and processed than authenticated requests. I would need to see the requests to find what is being excluded or broken.

---

<div class="post-metadata">

**Author:** ![zach](https://forum.pritunl.com/user_avatar/forum.pritunl.com/zach/32/1105_2.png) [@zach](https://forum.pritunl.com/u/zach)\
**Post date:** [October 27, 2023, 10:58am UTC](https://forum.pritunl.com/t/issues-with-permitted-paths-wrong-request-designs/1410/5 "2023-10-27T10:58:38Z")

</div>

This has been fixed in the latest release currently in the [**unstable repository**](https://docs.pritunl.com/docs/repo#unstable-repositories).
