meta.js is sent with the wrong MIME type

[bt90]

What happened?

The HTTP content-type seems to be wrong:

content-type: text/plain; charset=utf8

Paired with x-content-type-options: nosniff, the request is blocked by the browser.

see https://forum.syncthing.net/t/cant-login-to-syncthing-gui-with-ngnix-proxy-manager/22030

Syncthing version

v1.27.6

Platform & operating system

Linux amd64

Browser version

No response

Relevant log output

No response

[bt90]

Something is fishy:

syncthing/lib/api/api.go

Line 722 in 6204670

w.Header().Set("Content-Type", "application/javascript")

[bt90]

Ah, this is apparently caused by /meta.js not being exempt from our authentication check. Maybe we need to add /meta.js here?

syncthing/lib/api/api_auth.go

Line 54 in 6204670

func isNoAuthPath(path string) bool {

At least the content doesn't look sensitive to me:

var metadata = {
    "authenticated": true,
    "deviceID": "XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX",
    "deviceIDShort": "XXXXXX"
};

[calmh]

I don't follow. There's nothing wrong with the content type. It's behind auth, as many other things. The OP's issue seems to be some proxy problem together with trying to interpret a retuned 403 error.

[bt90]

The problem is that we're loading meta.js as regular frontend code:

syncthing/gui/default/index.html

Line 1080 in 6204670

<script type="text/javascript" src="meta.js"></script>

Once strict MIME type handling is enforced via X-Content-Type-Options: nosniff, this ends up as an error in the browser console.

Judging from a quick test, it doesn't break the UI even when X-Content-Type-Options: nosniff is added by a reverse-proxy. So it's more of an annoyance than a real bug and mostly not the cause of the problem observed by the user.

My proposal would be to exempt meta.js from authentication and instead populate its authenticated field dynamically:

syncthing/lib/api/api.go

Lines 717 to 721 in 6204670

	meta, _ := json.Marshal(map[string]interface{}{
	"deviceID": s.id.String(),
	"deviceIDShort": s.id.Short().String(),
	"authenticated": true,
	})

[calmh]

It doesn't break the UI at all as far as I can tell. There's an error in the console about it when you're not logged in, that's all. Potentially this could be nicer, perhaps we don't try to load the resource when not logged in, but I don't see a bug or problem here...

From what I can see in the forum thread the OP had some entirely unrelated problem with the proxy or their browser plugins and just latched onto this as the visible error in the console.

[bt90]

From what I can see in the forum thread the OP had some entirely unrelated problem with the proxy or their browser plugins and just latched onto this as the visible error in the console.

Aye. nginx-proxy-manager has some interesting config bits:

https://github.com/NginxProxyManager/nginx-proxy-manager/blob/v2.11.1/docker/rootfs/etc/nginx/conf.d/include/assets.conf#L8-L9