Be able to run AnsibleForms behind a reverse proxy (as a NGINX) and serving it from a sub path (not at webroot level).

[dariopai]

Is your feature request related to a problem? Please describe.
Ansibleform not working well behind a reverseproxy and being served from a subpath

Describe the solution you'd like
Defined the subpath in settings as in the case of Grafana => https://grafana.com/tutorials/run-grafana-behind-a-proxy/

Describe alternatives you've considered

Working on version: v4.0.10

When using nginx it can be managed using sub_filter & proxy_intercept_errors as below settings:

------nginx.con------

map $upstream_http_location $redirect_uri {
~azuretoken(.) https://host.domain.local/myAnsibleforms/#/login?azuretoken$1;
default $upstream_http_location;
}

location /myAnsibleforms/ {
proxy_pass https://10.1.1.1:8445/;
proxy_redirect off;
proxy_set_header Host $host ;
proxy_set_header X-Real-IP $remote_addr ;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for ;
proxy_set_header X-Forwarded-Proto https ;
sub_filter 'href: "/"' 'href: "/myAnsibleforms/"';
sub_filter '<title>Ansible Forms</title>' '<title>myAnsibleforms</title>';
sub_filter /css/ /myAnsibleforms/css/;
sub_filter /js/ /myAnsibleforms/js/;
sub_filter /api/ /myAnsibleforms/api/;
sub_filter /assets/img/logo_ansible_forms_full_white.svg /myimages/logo_custom.jpg;
sub_filter /assets/ /myAnsibleforms/assets/;
sub_filter /favicon.svg /myAnsibleforms/favicon.svg;
sub_filter 'myAnsibleforms/myAnsibleforms' 'myAnsibleforms';
sub_filter_once off;
sub_filter_types *;
proxy_intercept_errors on;
error_page 302 = @reDIrect;
}
location @reDIrect {
return 302 $redirect_uri;
}

Additional context
n/a

[ansibleguy76]

i assume you only have an issue with the subpath? never considered this requirement. will have to see how easy this is to implement.

[ansibleguy76]

I'll push this one back and will probably not fix this.

[dariopai]

pls consider this approach .. if you serve the app inside a subfoolder by default.. it should be easy to remap and/or mount it behind any existing reverse-proxy, otherwise it is necesary to have it in a dedicate hostname/hostheader El vie., 15 de dic. de 2023 2:21 p. m., AnsibleGuy76 < ***@***.***> escribió:

…

I'll push this one back and will probably not fix this. — Reply to this email directly, view it on GitHub <#106 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AOIBTFD4EUGDKAYWXWR2DLTYJRFGNAVCNFSM6AAAAAA6HRQ6OSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJXHA3TGOBVGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[ansibleguy76]

hi, it's not about not possible, it will break the entire rest api. i realize it needs a dedicate hostname.
The frontend application can run in a subfolder, but you must also consider the rest-api. I'll see what happens, I need to check if the swagger interface will still work then.

[ansibleguy76]

Hi, so I tried. It was quite a lot of changes. Will push a beta today with more info

[ansibleguy76]

New Beta is pushed. In the case you want to host ansibleforms in subfolder, for example https://af.domain.local/mysubfolder/.
You can use the environment variable BASE_URL. Set it to /mysubfolder/ (default is /). Please test it and send me feedback. i think I already tested everything, including the swagger interface.

[dariopai]

hi, today I was able to test this new feature in my K8S ["env variable BASE_URL"] and using the docker image [ansibleguy/ansibleforms:beta] ... and it seems it only works for https://localhost:8445/mysubfolder/api/v1/schema/xxx .. the rest of resources continue being served from /.

So 404 HTTP is returned when the webrowser tries to GET https://localhost:8445/api/v1/schema/xxx; but if I try manually https://localhost:8445/mysubfolder/api/v1/schema/xxx, the webapi works ok. I was able to fix temporarily this issue with a custom nginx-replace-rule in my reverse-webproxy running in front of the AF-webportal.

Could it be possible?

[ansibleguy76]

Hi, I tried realy hard, but it seems this is not possible. On the backend its easy to have it dynamically but on the frontend it seems very hard. The frontend app is being built and the paths are not dynamic. I have asked for help in stackoverflow, maybe there is a magic setting but for now it just doesn't work. I will remove it from the help file so it doesn't confuse anyone.

[dariopai]

Hi, if you need some help on this please let me know that I'm also a programmer!

---new update---

I've tested it again with v5.0.3 inside my k8s, and although the whole app seems to be OK and be served inside the subfolder, the URLs generated to download the static resources are pointing to the root "/". Maybe this can add some clue to the issue (attach-files with the debug)
...
And related to this issue... in version 5.x I'm not able any longer to redirect the MS Entra ID (AzuerAD) callback URL to a subfolder as I used to do in my NGINX rules with version 4.x (reverse proxy to k8 services). It seems you have added a new security verification in v5.x that forces the callback to be only at "/api/v1/xxx"... so my question now is if there is any way to avoid this checking so to make the reverse proxy works as in version 4.x and inside a subfolder.
....
ERROR in V5 but not in V4 >> TokenError: AADSTS500112: The reply address 'https://xxxx.xxx.xx/api/v1/auth/azureadoauth2/callback' does not match the reply address 'https://xxxx.xxx.xx/my_subfolder/api/v1/auth/azureadoauth2/callback' provided when requesting Authorization code. Trace ID: ca055e5d-b516-425c-8a02-XXXXXXXXXX Correlation ID: 334a19c5-362e-4e1c-9d20-a8f36a5e5668 Timestamp: 2024-06-27 12

K8S POD LOG

CURL TO AF FROM INSIDE POD

BROWSE DEBUG

[ansibleguy76]

I see only one way : after the client app is built, analyse the built and convert it to dynamic code on the server side.

[dariopai]

It could be also useful to be able to edit and change CALLBACK URL for the case of the MS ENTRA ID integration; since if AF is running behind a reverse proxy (as in the K8S case) not always you can keep the same subfolder to reach it. At version 5.x, as I explained in my prev post, only the callback at root level is permitted... although if BASE_URL were working as expected, this feature probably could not be always needed.