Issues with cookies when using latest Passenger and Rack 3 (w/ Ruby on Rails 7.1) about passenger HOT 20 CLOSED

@mitchellhenke no. The release is done, just sadly being held up by some CI issues we're sorting out.

from passenger.

So secure cookies do seem to work just fine after more testing. The issue appears when usingconfig.force_ssl = true which includes the SSL middleware (https://github.com/rails/rails/blob/main/actionpack/lib/action_dispatch/middleware/ssl.rb)

The commit to make the middleware compatible with Rack 3 rails/rails@9d840a1 changed to the array format at https://github.com/rails/rails/blob/9d840a17197ffa5dec8cb2d4171450dfa12c156f/actionpack/lib/action_dispatch/middleware/ssl.rb#L116 which breaks passenger.

That's why using config.ssl_options = {secure_cookies: false} makes things work because it skips the function that converts to an array.

from passenger.

If someone feels like helping, I pushed 7353892 to hopefully fix this, so you could test it and report back.

from passenger.

Well, that's good enough to fix this bug, if you want to request other features, perhaps open a separate feature request.

from passenger.

Hello @CamJN any update regarding the release?

from passenger.

@CamJN this is but one of several changes required to support Rack 3.

I think a better short term option would be to detect Rack.release and fail if it's not a compatible (e.g. < 3 I suppose at the moment).

You should also consider adding a PR to test Rack 3 with Passenger to https://github.com/socketry/rack-conform - this will bring attention to Rack 3 specific issues. You should also consider running your own test suite with Rack::Lint from Rack 3.

from passenger.

@ioquatix according to https://github.com/rack/rack/blob/main/UPGRADE-GUIDE.md

There is one changed feature in Rack 3 which is not backwards compatible
Response header values can be an Array to handle multiple values (and no longer supports \n encoded headers).

from passenger.

Playing around a bit with my Rails config, I can get Rails 7.1 working with Rack 3 if I change the ssl_options to be:

config.force_ssl = true # this is already the default for production apps
config.ssl_options = {secure_cookies: false} # added this config option otherwise cookies break if secure cookies is true

Not saying you should make this change to get your apps working in production, but it appears as though this is only a secure cookies issue.

from passenger.

For this specific issue, the correct solution is for Passenger to correctly handle response headers which can be an Array of values. In addition, using newline characters is no longer supported in Rack 3.

• Rack 2 semantics: https://github.com/socketry/protocol-rack/blob/98b6648014d3b57b956f457f41fecf3a810b2426/lib/protocol/rack/adapter/rack2.rb#L100-L121
• Rack 3 semantics: https://github.com/socketry/protocol-rack/blob/main/lib/protocol/rack/adapter/rack3.rb#L65-L86

from passenger.

I know that we can force to use gem install rack -v 2.2.4 to avoid this issue for now. But are there any plans to support Rack 3.x?

BTW, currently when you install passenger gem, it will automatically install Rack 3. Which I believe renders it impossible to run any Rails application without issues with cookies.

https://github.com/phusion/passenger/blob/467259e673ec66b121b10eff1dd84ac1188ea3d2/passenger.gemspec#L26C3-L26C26

from passenger.

I will try to fix this, but am currently swamped trying to fix our CI, you may have noticed the 6.0.19 release is quite late at this point. A PR would be much faster than waiting for me to fix it, but I'll get to it eventually, it just likely won't be in the next release.

from passenger.

BTW, currently when you install passenger gem, it will automatically install Rack 3. Which I believe renders it impossible to run any Rails application without issues with cookies.

To add to the equation: even if you don't use Passenger gem, Ruby on Rails 7.1 now uses Rack 3 by default. So, upgrading an app to Rails 7.1 will break the app if it relies on cookies for authentication of their users. And it doesn't fire any log message, many think it's a Rails issue and it's not. So the devs are blind about this and the root of the problem.

from passenger.

Just got bitten by this! In our test pipeline we use puma because installing a full apache there is a hassle, and trying out the site on a staging server appeared to work fine because the browsers we tried with apparently still had a cookie from Rails 7.0.8 / rack 2.

After 10 minutes in production our help desk started to light up with "can't log in" messages... ouch. More people are going to get bitten by this, you may want to send an email to your users to warn them. @FooBarWidget

from passenger.

That's "the one changed feature which is not backwards compatible" but there are other new features which you must support and handle correctly at the server level, most notably streaming.

from passenger.

Thanks for passenger and appreciate the quick fix! Is there anything I can do to help get the change released?

from passenger.

@rmatovu987 see the comment immediately before yours.

from passenger.

This is blocking a critical bug fix with another gem for us :(

from passenger.

@benkruger why can't you just stick with Rack 2.2 for now? Even once @CamJN gets CI working and lands this fix 🙏, it's our choice to jump into Rack 3 or wait for things to smooth out. They'll get there in time.

With my apps, we're going to stay a bit cautious given #2503 (comment) is authored by someone who has some authority on Rack conformance, and his nice suggestion would help Passenger find and fix any other Rack 3 compat issues that could be lurking, and demonstrate that Passenger is ready for production use with Rack 3.

from passenger.

@akaspick SSL or not should not matter to the way cookies are set. What you may be seeing (what tricked me at some point) is that cookies set by rack 2 will work fine on rack 3. So I would be interested if you can reproduce this after clearing your cookies.

from passenger.

@Fjan I tested this with all my cookies deleted first so it could create new ones. In my web console, I could see the secure cookie being set with my original config and things didn't work. Cleared cookies, changed to unsecure cookies, and the unsecure cookie was set and worked.

Anyway, this change in the secure setting seems to make a difference for some reason.

from passenger.