[Question]: LibreChat not working behind nginx reverse proxy with basic_auth #890
Contact DetailsNo response What is your question?I'm pretty inexperienced with web stuff so bear with me. I'm trying to self-host Librechat the way I do my other apps: behind an nginx webserver which acts as a reverse proxy. I put everything at subdomain.domain.com, in this case I wanted gpt.domain.com. nginx uses basic_auth to protect access to each subdomain. Librechat loads, but the API calls are not working, so it does nothing. If I access Librechat directly (on plain HTTP port 3080 instead of going through nginx), it works fine. But I don't want to do that for security reasons. My nginx.con uses the exact same server block for Librechat as for my other stuff: Nginx's access.log shows that nearly all calls after the initial page load, such as 'GET /api/whatever', are returning 401 (which I think should show an error btw). I modified nginx's log template to add info (user=, auth=, returncode=), and I notice that the failed calls all have a different auth style. On my other apps (eg QBittorrent), I always see user=myusername, auth=Basic, and all calls 200 OK. LibreChat is different, it's an empty user=-, and auth=Bearer instead of Basic with a weird token that's like 5x longer. Can I do anything about this? Is Librechat compatible with basic_auth? relevant nginx.conf block: access.log More DetailsNone What is the main subject of your question?User System/OAuth ScreenshotsNo response Code of Conduct
|
Replies: 5 comments 5 replies
|
LibreChat has its own built-in authentication system, so it won't know how to handle the one you're passing through to the API. I found this ChatGPT answer helpful here: The issue you're facing is due to a conflict between the Here's a breakdown:
The problem arises when LibreChat tries to make an API call. It sends the Here's how you can resolve the issue:
server {
listen 443 ssl;
server_name gpt.*;
include /config/nginx/ssl.conf;
location / {
auth_basic "Restricted";
auth_basic_user_file /config/nginx/.htpasswd;
include /config/nginx/proxy_params.conf;
proxy_pass http://LibreChat:3080/;
}
location ~ ^/api/ {
auth_basic off;
include /config/nginx/proxy_params.conf;
proxy_pass http://LibreChat:3080/;
}
}
After making these changes, restart Nginx and test again. The API calls from LibreChat should now work correctly through the reverse proxy. |
|
One thing to note, when using NGINX, it's expected to proxy pass to API still, so a working file may look more like this, again according to GPT. Given the default Nginx configuration for LibreChat, it's clear that the application expects to be directly proxied without any additional authentication layers. The default configuration is set up to forward all To integrate Basic Authentication while ensuring that LibreChat's API calls work correctly, you can modify the configuration as follows:
Here's a modified configuration based on your requirements: server {
listen 80;
listen 443 ssl;
# ssl_certificate /etc/nginx/ssl/nginx.crt;
# ssl_certificate_key /etc/nginx/ssl/nginx.key;
server_name gpt.domain.com; # Change this to your domain
# Exclude API calls from Basic Authentication
location ~ ^/api/ {
auth_basic off;
proxy_pass http://api:3080/api;
include /config/nginx/proxy_params.conf;
}
# All other requests will have Basic Authentication
location / {
auth_basic "Restricted";
auth_basic_user_file /config/nginx/.htpasswd;
proxy_pass http://api:3080;
include /config/nginx/proxy_params.conf;
}
}A few things to note:
After making these changes, restart Nginx and test the setup. You should be prompted for Basic Authentication when accessing the main page, but the internal API calls made by LibreChat should work without any issues. |
|
The reason I use basic_auth is because I have fail2ban installed on my server and it reads nginx's access logs and auto-ban any IP that fails too many nginx logins (HTTP 401). (for example those 401 in my access log would have gotten my own IP banned if I kept using them). Instead of worrying whether any of the many apps I self-host is properly secured by the developer, I just let nginx+fail2ban take care of auth, and I don't have to care. Even if your app has zero security, I'm unhackable this way. It's a very common setup among casual self-hosters like me who want to set something up and forget about it for months. I went with option 1. What ChatGPT gave you has a small issue, it gives the error: "proxy_pass" cannot have URI part in location given by regular expression, or inside named location, or inside "if" statement, or inside "limit_except" However, removing the trailing slash at the end of proxy_pass (after :3080) fixes it. So here's the corrected configuration block: And with this, I'm a happy camper. Thanks Danny! I think this solution should be in the docs somewhere ("Using Librechat behind a secured reverse proxy"). These instructions are specific to nginx but Apache and Caddyserver will have the same solution and should be easy to translate for other users. What matters is the solution. |
|
That’s awesome, glad you figured it out!! Would you mind doing a write up for the docs? If not I can get around to it, but that is a neat use case |
|
I will have to add that you should also add a rule to add basic auth for the API registration route or just simply set or even omit the following env variable in your .env file: ALLOW_REGISTRATION=false you can test this with a postman request that registration will not be allowed and therefore none of the api routes will be accessible |
|
a long time coming but I've gotten the docs updated now: #1118 |
|
May I ask how basic auth will help for "worrying whether any of the many apps I self-host is properly secured" if the API itself is still not protected? Any vulnerability there would still be a risk, or am I missing a crucial point here? PS: The reason for my comment is that I'm also intending to use LibreChat on a public server and I'm a bit hesitant regarding the security implications. |
|
@passaca LibreChat is secure against unauthorized requests. I've been running my instance on a fairly public domain with cloudflare protection and using HTTPS, no issues. Granted, there is always more that can be done as you imply. The added security that Basic Auth offers is to prevent a user from ever becoming authorized in the first place, unless they have those basic auth credentials. On top of this, to really protect your instance, you need to make use of the automated moderation settings: https://docs.librechat.ai/features/mod_system.html |
|
No problem. Here's the write-up, copy-paste it where appropriate in the doc: Using LibreChat behind a reverse proxy with Basic AuthenticationIf LibreChat is behind a webserver acting as a reverse proxy with Basic Auth (a common scenario for casual users), LibreChat will not function properly without some extra configuration. You will connect to LibreChat, be prompted to enter Basic Auth credentials, enter your username/password, LibreChat will load, but then you will not get a response from the AI services. The reason is that LibreChat uses Bearer authentication when calling the backend API at domain.com/api. Because those calls will use Bearer rather than Basic auth, your webserver will view this as unauthenticated connection attempt and return 401. The solution is to enable Basic Auth, but disable it specifically for the /api/ endpoint. (it's safe because the API calls still require an authenticated user) You will therefore need to create a new rule that disables Basic Auth for /api/. This rule must be higher priority than the rule activating Basic Auth. For example, for nginx, you might do: |
|
Thank you for the answer, because if you do it according to the documentation there is a confusion, and I need the chat room to receive just output by 443 without using port 80. |
The reason I use basic_auth is because I have fail2ban installed on my server and it reads nginx's access logs and auto-ban any IP that fails too many nginx logins (HTTP 401). (for example those 401 in my access log would have gotten my own IP banned if I kept using them).
Instead of worrying whether any of the many apps I self-host is properly secured by the developer, I just let nginx+fail2ban take care of auth, and I don't have to care. Even if your app has zero security, I'm unhackable this way. It's a very common setup among casual self-hosters like me who want to set something up and forget about it for months.
I went with option 1. What ChatGPT gave you has a small issue, it gives …