Response header too long for default nginx configuration

[Gargron]

Steps to reproduce

Doorkeeper is used in Mastodon. An app developer encounters error when trying to authenticate a user through OAuth with a long URL or a long state param, which causes Doorkeeper to return a response with a header so long that it causes nginx to return HTTP 502 when using default proxy buffer values.

Please see linked issue mastodon/mastodon#12915.

Expected behavior

Either:

• OAuth response is returned that can be processed by nginx correctly
• An error is raised in Ruby because user input is too long
• Documentation is updated to advise about min. required proxy buffer size

Actual behavior

• OAuth response contains such a long header it causes a HTTP 502 upstream sent too big header while reading response header from upstream error in nginx with default proxy buffer sizes

System configuration

Doorkeeper initializer:

https://github.com/mastodon/mastodon/blob/50ab3f3dcb6b00109fa1462a5ca0228563abb99b/config/initializers/doorkeeper.rb

Ruby version: 3.0.3

Gemfile.lock:

https://github.com/mastodon/mastodon/blob/50ab3f3dcb6b00109fa1462a5ca0228563abb99b/Gemfile.lock

[snarfed]

@nbulaj any thoughs? Our OAuth client app has been dead in the water for a while because of this. (Thank you in advance for looking!)

[nbulaj]

Hi @Gargron @snarfed
I don't sure what RFC and security considerations documents say about that. Have to check, maybe there are some restrictions which should be made on Doorkeeper level
Otherwise doesn't it must be configured via nginx (or any other web server)?

[nbulaj]

I didn't find anything about input data size in https://datatracker.ietf.org/doc/html/rfc6819 (but could be that I looked up wrongly), but we can add some pre-defined restrictions for the size of the params/headers/whatever which could be configurable in the initializer. WDYT?

[snarfed]

@nbulaj thank you for looking! How would these restrictions behave? Would they truncate the too-long response header? If the OAuth handshake still works, then that would be great. Otherwise, if they simply reject long URLs, then that wouldn't help us much, since we want this to actually work.

If it helps, we're generally seeing this error with URLs around 550 chars. That's long, but not crazy; the de facto limit in browsers is generally around 2000.

Here's a formatted, redacted example URL. The long query params are state, 194 chars, and scope, 128 chars.

https://mastodon.technology/oauth/authorize
?response_type=code
&client_id=2f0M.......................................
&client_secret=Jy5D.......................................
&scope=read:accounts%20read:blocks%20read:notifications%20read:search%20read:statuses%20write:statuses%20write:favourites%20write:media
&redirect_uri=https%3A%2F%2Fbrid.gy%2Fmastodon%2Fcallback
&state=%7B%22app_key%22:%22agdi...........................................%22,%22state%22:%22%257B%2522feature%2522%253A%2522listen%252Cpublish%2522%252C%2522operation%2522%253A%2522add%2522%257D%22%7D

More background in mastodon/mastodon#12915 (comment).

[snarfed]

Friendly nudge here, this is still visibly affecting a number of our users, I field questions about this regularly. Let me know if I can do anything else to help, beyond the debugging info above!

[thom4parisot]

So if I understand well, this is due to an arbitrary limit set by the gem? Which is likely to be hit in (some kind of) OAuth apps?

[nbulaj]

There is no limits by the gem @thom4parisot . OAuth RFC also doesn't say anything about limiting client URL so I don't sure which fix here will be acceptable

[snarfed]

Interesting workaround in mastodon/mastodon#12915 (comment). This error happens if you're already logged into the Mastodon instance, but if you're not logged in when you start the OAuth dance, it works fine. Does that give you all any more ideas for what to do here?

[jonnybarnes]

A possible fix for this is to modify the nginx conf to increase the proxy buffer. The following worked for me:

    proxy_buffers 4 16k;
    proxy_buffer_size 16k;
    proxy_busy_buffers_size 32k;

[timnolte]

A possible fix for this is to modify the nginx conf to increase the proxy buffer. The following worked for me:

    proxy_buffers 4 16k;
    proxy_buffer_size 16k;
    proxy_busy_buffers_size 32k;

Confirming that adding these setting in my nginx configuration specifically for my Mastodon instance fixed the 502 errors when authenticating with Brid.gy.

[tmichellemoore]

Hello Doorkeeper Team! Have you all reconsidered implementing the fixes above so that users can authenticate Mastodon publishing through Brid.gy?
@nbulaj @felipeelias @Gargron @snarfed

[snarfed]

I ended up working around this by storing the OAuth redirect state in memory on my end, which let me reduce the redirect URL length. I'll leave this open to track on Doorkeeper's end.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.