I already check the nginx documentation.
even with the method you suggest I get the some behaviour as before
the login fails . and not database is selected.
the problem is that in the log of tryton and in the log of the browser i do not have any information !!!
I also try in this way but with no success
location ~ ^/tryton/(.*)$ {
proxy_pass http://192.169.154.102:9999/$1;
}
regards
Matteo
You can use the -v flag (more flags more logging details) to increase trytond logging. Or you can set a custom logging configuration
If no database is listed this means that you are not connecting with the right server. So for me the problem is on the nginx configuration.
This may be the clue to solve the problem. By default tryton will only listen to 127.0.0.1 and not to the lan IP (192.168.154.102).
Did you tried using localhost or 127.0.0.1? (which is the same).
copy paste error in the server is correct because the login page appear
I think it is quite difficult to get Tryton/Sao to work if it is in a subpath. If I am not mistaken, after the login page is served from DOMAIN FOR SALE the subsequent POST requests from Sao go back to www.myDomain.org and not DOMAIN FOR SALE. This is why it works with listen = 0.0.0.0:8000, because in this case trytond is replying directly to the POST requests, instead of via nginx.
Are you sure? Note that nginx will cache all the static files so if your seen the page on time it will be shown correctly when the server is not properly configurad.
You can see in your logs from frist post that it responds with 304 ( which means no modified ) so the server does not send any file and the browser loads the files from it’s cache.
Indeed as far as I know subpath is not really working. But if someone wants to propose a patch to support it, it will be welcomed (even if it is not really a priority).
I’ve tested and I can confirm that it’s not working. I’ve started to write a patch but it is not fully working. I can logging but the menu screen is not properly loading. I need some more time to test it.
I will share my process latter.
I’ve filled Issue 9239: Allow to deploy sao on subpath - Tryton issue tracker which add soport for supbath on sao.
@mboscolo could you please apply it to your setup and test it works correctly?
I’ve also posted on the issue the required nginx configuration to make it work.
Dear @pokoli I check the patch and I’m able to see the database list and login correctly to the sao client.
I also try to create and save entity and it looks to work smoothly.
many thanks for the patch.
regards,
Matteo
Don’t you proxy only the POST requests and use nginx to serve SAO?
No because we use the sao images which already contains sao and are configured to server it’s static content. So we use nginx to proxy the request directly to the container, manage ssl certificates (using letsencrypt).
This allows to receive all updates (python code and sao) by pulling the docker images.
I guess you mean Tryton docker image, don’t you?
So SAO is served from Tryton through uwsgi.
We mount SAO from Tryton docker image in a nginx container to serve SAO from there. We thought that maybe Nginx would be more efficient in this task than uwsgi. Do you think it is worth to serve SAO from nginx instead of uwsgi?
As we have nginx installed on the host (we redirect based on the host to diferent ports environments) we do no think we need an extra container for serving static files. But normally there is no way that works for all.
Hello Mateo,
I’m working on trytond 5.0 version how did you applied this patch? I’m facing exactly the same issue right now with nginx.
Thanks
I test it in 5.4.
I was able to make it work on firefox, but chrome give me the some behaviour
Regards,
Matteo
It will be great if you can explain what errors did you found on the issue.
Hello @pokoli
I had similar issue using flask_tryton but I solved with gunicorn and SCRIPT_NAME param, I saw this : https://uwsgi-docs.readthedocs.io/en/latest/Vars.html and seems that uwsgi has something similiar uwsgi_param SCRIPT_NAME /testapp;
Do you think this could apply to SAO also? sao use uwsgi or… not possible in that way. Just asking 
No, his is unrelated. Sao neeed to be adapted (as well as tryton) because they manage to build the correct url when deployed on a subpath. That’s why I created the issue.
Hi! I am facing same issue. My nginx configuration goes:
location / {
root /srv/www/htdocs;
index index.html index.htm;
}
location /tryton/ {
proxy_pass http://localhost:8000/;
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-Host $server_name;
}
I can see the tryton login, but once I tried to log on it gave me the ‘not found’ error message. There is something missing on nginx, I know, but don’t know what.
subpath is still not supported see Issue 9239: Allow to deploy sao on subpath - Tryton issue tracker