#MCP server not working behind reverse proxy

1 messages · Page 1 of 1 (latest)

idle flower
#

One of the biggest 2.9 features I cared about is the MCP server. It would let me use any features without having to do as much research.

Sadly, this MCP server doesn't work for me because I host the container off TrueNAS Docker with an nginx-proxy-manager in front. Because of that, it keeps erroring that I'm not using HTTPS even though I am.

I had Claude make a PR: https://github.com/music-assistant/server/pull/4313 with the fix. I don't know Python, so this is the best I could do.

GitHub

What
Adds an opt-in trust_forwarded_proto config option to the MCP Server (fastMCP) provider so the Connect Wizard works behind a TLS-terminating reverse proxy.
Why
The wizard's credential-...

idle flower
#

I tested this locally in my Docker container, and I was able to get connected to the MCP server finally!

bleak trench
#

I posted a link to our AI Policy in your PR

I had Claude make a PR: with the fix. I don't know Python, so this is the best I could do.

You cannot just post AI generated content. You need to be able to explain the PR in your own words.

idle flower
#

Understandable.

I misread the policy the first time through anyway. I thought it said "no AI", but it said "no autonomous AI" which is kinda the position I'm in.

I barely understood the issue. It's very deep SSL/TSL. Basically, something about the forwarded header isn't working with Music Assistant MCP, so I had to get that working. The exact specifics... I don't know. It's something to do with a reverse proxy and how the MCP server reads the URL.

But I did try it locally as well because I wanted to make sure the PR worked.

How should I say this... I took the same amount of effort for this PR as I do at work except I don't know Python enough to say either way.

I figure someone "in the know" could tell me if anything's up, and I can fix anything requested of me with the PR.

#

The biggest issue with the PR is the massive amount of AI comments. I can ask it to remove those, but they do give context.

bleak trench
#

We don't have time to review something that you don't understand.

idle flower
#

What would I need to understand in the future for any AI-generated PRs to be acceptable?

bleak trench
#

You need to understand all of it and explain it in your own words.

idle flower
#

I mean, this is how I'd describe the issue myself (attached image).

I don't know all the HTTPS terms, but because there's a reverse-proxy, Music Assistant isn't seeing the "HTTPS" in my URL, it's using the "HTTP" from the localhost address that nginx-proxy-manager is proxying from.

The important piece of this PR is fixing fastmcp to look at the URL I'm using, not the proxied URL by X-Forwarded-Proto.

What that is? I have no clue. But that's the thing that I saw in NGINX-proxy-manager (attached image). I have it disabled, but Music Assistant MCP wasn't honoring that.

There's a "guard" thing in the code that the MCP server uses to avoid minting tokens in an unsafe way. But because my URL is HTTPS, then it should be fine even if the origin is localhost.

I understand that much. I just don't know python. I understand code, I understand comments, I understand the generalities of HTTPS.

I have absolutely no clue what X-Forwarded-Proto nor X-Forwarded-Scheme are and how they're related to proxies, but I know that those things are related to why this broke.

What I'd like help with is the Python. Some spots in the code a suspect such as how it's splitting the headers (attached image). I don't have a good way to explain why that is or isn't good.

#

I work with a lot of code that I don't really truly understand, but I know that if I change X, Y works.

So I'm trying to understand what you need outta me because I planned to do more PRs like this to help out the project.

Is what I know enough or are you specifically wanting a better background on Python and those HTTP proxy headers?

bleak trench
#

I am asking you to comply with the AI Policy.

idle flower
#

you are responsible for any contributions you submit
Yes. This is fine.

We do not allow autonomous agents to be used for contributing to our projects.
That's understandable. I didn't just say "fix the issue", I worked on this with Claude, going through a bunch of configs, NGINX, Music Assistant, etc.

I had it look at the code and see if it could find the line in question causing the proxied headers to not be accepted.

I even tested the fix locally and made a PR. This was a few hours of my time even with AI.

We don't mind if you use AI tools to help you write. However, do not have tools post unreviewed content on your behalf. Keep responses to the minimum needed to communicate your intent. We may hide any comments that we believe are unreviewed AI output.
I 100% reviewed the code, but there are some things I didn't understand. I noted those in the PR just now.

If you asked me questions, I could get the answers necessary 💯.

We understand that AI is useful when communicating as a non-native English speaker.
I'm a native English speaker and a professional software engineer in the US.

All contributions must be reviewed and understood by the contributor before submission. You should be able to explain every change in a pull request you submit. Pull requests that appear to be unreviewed AI output will be closed without review.
I can absolutely explain the changes, just not if they're good Python code.

#

Is that good?