search

altcha-org / forms

ALTCHA Forms enables secure data collection through forms. Compliant with GDPR and HIPAA.
https://altcha.org/forms
GNU Affero General Public License v3.0
8 stars 3 forks source link

Self Hosted - Multiple Issues #3

Closed zgjimgjonbalaj closed 1 week ago

zgjimgjonbalaj commented 3 weeks ago

Thanks for all your work on this and for sharing. I am having some issues getting this to work. I've tried hosting this in two separate environments with the same .env and docker compose file and oddly enough am getting two separate issues. In both instances however this is behind nginx proxy manager.

Issue 1:

In a server within my home network I was able to get everything up and running and even setup a form. When I would click the "Open" form button this would result in a 502 from Cloudflare. No log entries from altcha however and no information on why this was occurring. I tried several different ways to debug but unfortunately the BASE_URL is very limiting in that I cannot try to access the https://configured-domain.tld/form/

through a local IP without but have to go through CF. Everything worked in this scenario including SMTP and getting forms to preview but was just unable to actually open a form at all.

Issue 2:

After a few repeated attempts on my local environment I thought let me give this a shot on a server I have elsewhere. Uploaded the same configuration got it running and now the weirdest thing is I cannot even get past authentication. Each time I enter any email address on initial setup it says "Invalid Email Address". I thought I'd try enabling Github OAuth so added the client ID & secret and am now getting a "Server Error" each time it tries to authenticate. It goes successfully through OAuth and when it redirects to callback URL I see the GET params that Github has added but the screen just shows "Server Error" above the "Authenticate" button.

I was also unable to find anywhere in the docs what the callback URL for OAuth should be so I used domain.tld/app/oauth/github/callback/ (with and without trailing slash). This was the only URL that seemed to not cause a 404 but still no success.

ovx commented 3 weeks ago

Hi, thanks for giving it try. The documentation is still work in progress, I'll add some more information about self-hosting soon.

Issue 1: The "Open" link uses the current origin so if you have the app open on 'localhost' it will use that domain regardless of the configured BASE_URL (although that should be changed). If you don't expect it to point to cloudflare, it might be just misconfiguration of DNS records on your network. The form's URL is this format {domain}/form/{form_id} so you can try to construct the url manually with the domain name you're expecting to work.

Issue 2:

zgjimgjonbalaj commented 3 weeks ago

Hey @ovx,

Thanks for your responses here. Looks like maybe I didn't clearly state the issue or am misunderstanding your responses.

Issue 1:

I am opening the app via my public domain mydomain.com/app which is on CF and the app itself is also attempting to open the form via the correct domain mydomain.com/form/{form_id}. All other pages and links are also working properly with this domain which is configured as the BASE_URL env variable. The issue seems to be that when opening mydomain.com/form/{form_id} via the "Open" link in the form editor CF is returning a Bad Gateway response. This usually happens if the app itself is not responding to that URI/Path or not returning anything maybe. It is also only these form URL's so far that are causing issues. I wonder if there is a setting within NPM (reverse proxy) that must be applied to these URLs to work? I don't think this is CF related and am willing to be it's either NPM or the app itself. I have not tried the localhost config approach yet since I don't have the DNS configurations in place to access these docker containers with IP:PORT and just use subdomains of mydomain.com.

Issue 2:

ovx commented 3 weeks ago

Issue 1: if the url is correct, but connection fails, it would suggest that the app crashes during form render. Try to create a new basic form with one text field, if it works. There should be something in the logs as well. NPM proxy should not play any role if the build succeeds.

Issue 2:

zgjimgjonbalaj commented 2 weeks ago

Issue 1:

Tried a blank form, form with just one field same result, nothing in the logs either. Is there a verbose setting somewhere where I may be able to view all traffic & responses by any chance? CF is just responding with 502's so not seeing much.

I did a bit of packet sniffing in Wireshark and in fact 2 requests I made show the app responding with HTML. 172.20.0.11 is the app whereas 172.20.0.4 is the proxy for it. image

The response code is OK 200 but can't figure out why this is not being passed onto CF at this point. Seems there may be an issue with this running behind a proxy like NPM. The following is the text/html that the app responded with:

image

Issue 2:

Ah ok got it, that gives me a good idea where to look. My firewall might be blocking some of these DNS requests. Thanks!

ovx commented 2 weeks ago

I don't see any reason for Cloudflare to return 502 if the response from the app is 200. The SaaS version is also behind Cloudflare and it works fine. If you're using some other proxy, maybe it messes up the response headers or something.

There's no verbose mode for logging atm, but Its a good idea to add it.

zgjimgjonbalaj commented 2 weeks ago

Just figured this out this morning...

The issue seems to be with the app sending too large headers to the proxy in its response for these URLs. The exact error I saw in my nginx error logs is:

2024/07/11 15:43:09 [error] 391#391: *70 upstream sent too big header while reading response header from upstream, client: 172.20.0.1

It seems the default proxy config will not work in this case. I guess the question is why larger headers were sent in the form URL's vs others but not opening that can of worms right now. If you want a workaround you can go in and add proxy buffer directives to the config. I was able to get it to work with the following numbers (adjust as needed):

proxy_buffer_size 128k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;

After adding this to the host, the forms load for me just fine. Is there any documentation on how we can implement these forms via iframe, API or how we can submit to them from a page? I haven't come across anything in this area and was curious to test one.

ovx commented 2 weeks ago

Hi,

zgjimgjonbalaj commented 1 week ago

Hey @ovx ,

Thanks for your response.