You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In https://github.com/ElMassimo/request_store_rails/blob/master/lib/request_store_rails/middleware.rb#L27env['action_dispatch.request_id'] || env['HTTP_X_REQUEST_ID'] are used as the base for request_id - why not always generate a random one? Using the forwarded request_id seems to allow room for accidentally sharing the RequestLocals, e.g. in a scenario of a multi-threaded web server that makes another request with forwarded request_id which ends up being processed on the same server instance.
The text was updated successfully, but these errors were encountered:
Some applications benefit from sharing the cache across requests with the same id that are being handled concurrently, but I agree it would be safer not to rely on the request id provided by the ActionDispatch::RequestId middleware, which might be useful for tracing purposes but leaves room for accidents in this use case.
Will cut a new release that uses SecureRandom.uuid instead.
In https://github.com/ElMassimo/request_store_rails/blob/master/lib/request_store_rails/middleware.rb#L27
env['action_dispatch.request_id'] || env['HTTP_X_REQUEST_ID']
are used as the base for request_id - why not always generate a random one? Using the forwarded request_id seems to allow room for accidentally sharing the RequestLocals, e.g. in a scenario of a multi-threaded web server that makes another request with forwarded request_id which ends up being processed on the same server instance.The text was updated successfully, but these errors were encountered: