Rails 3 正在更改来自 AIR 的 POST 会话 ID

发布于 2024-10-20 08:32:51 字数 1471 浏览 3 评论 0原文

我在 Rails 3 中有一个 REST API,有时从 AIR 应用程序访问,有时从浏览器访问。

我认为这是 Rails 3 的问题,但也可能是 Flex/AIR 的问题。

Rails 应用程序使用omniauth 进行身份验证,使用cancan 进行授权,并使用active_record_store。我使用会话模型来存储用户的身份。

(我不使用 cookie 会话是有原因的,与 AIR for Android、OAuth 和 StageWebView 有关。)

我使用 Charles 来监视 HTTP 流量。

大多数请求都可以正常工作。浏览器(或 AIR 客户端)使用 Cookie http 标头将会话 ID 发送到服务器,如下所示:

_session_id=950dee7eca6732aa62b5f91876f66d15

Rails 找到会话,找出用户是谁,然后执行其操作。

但在某些情况下,Rails 在发送响应之前会生成一个新会话。它将会话添加到会话表中,并使用会话 ID 将 Set-Cookie 标头返回给客户端。像这样:

_session_id=e1489a6b610c0a1d13cec1454228ae47; path=/; HttpOnly

发生这种情况的情况是:

  • 请求来自 AIR 客户端
  • 请求是 POST

这显然是一个问题,因为在后续请求中,Rails 无法找到用户信息。它创建了一个没有该信息的新会话。

所以我正在查看 POST 请求的 HTTP 标头。这是查尔斯的复制/粘贴;我在标题名称后面插入了冒号以使其可读。

Host: localhost.seti.hg94.com:3000
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/531.9 (KHTML, like Gecko) AdobeAIR/2.6
Referer: app:/AndroidApplication.swf
X-Flash-Version: 10,2,152,22
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Cookie: _session_id=950dee7eca6732aa62b5f91876f66d15
Content-Length: 84
Connection: keep-alive

有人知道为什么Rails会在这种情况下生成一个新会话吗?这似乎是在我的控制器代码执行之后发生的,因为我在控制器中拥有正确的会话信息。

我正忙着尝试进一步隔离问题、从 AIR 内控制标头等等。我已经研究这个错误近一周了。因此,来自社区的任何见解或建议将不胜感激。

I have a REST API in Rails 3 being accessed sometimes from an AIR application and sometimes from the browser.

I think this is a Rails 3 problem but it might be a Flex/AIR problem.

The Rails app uses omniauth for authentication, cancan for authorization, and active_record_store. I use the session model to store the identity of the user.

(There is a reason I'm not using cookie sessions, having to do with AIR for Android, OAuth, and StageWebView.)

I'm using Charles to monitor HTTP traffic.

Most requests work fine. The browser (or the AIR client) sends the session ID to the server using the Cookie http header, like this:

_session_id=950dee7eca6732aa62b5f91876f66d15

And Rails finds the session, figures out who the user is, and does its thing.

But under certain circumstances, Rails generates a new session before sending the response. It adds a session to the sessions table, and returns a Set-Cookie header to the client with a new session ID. Like this:

_session_id=e1489a6b610c0a1d13cec1454228ae47; path=/; HttpOnly

The circumstances under which this happens are:

  • The request comes from the AIR client
  • The request is a POST

This is obviously a problem, because on subsequent requests, Rails can't find the user information. It created a new session without that information.

So I'm looking at the HTTP headers for the POST request. Here's a copy/paste from Charles; I inserted the colon after the header name to make it readable.

Host: localhost.seti.hg94.com:3000
Content-Type: application/x-www-form-urlencoded
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en) AppleWebKit/531.9 (KHTML, like Gecko) AdobeAIR/2.6
Referer: app:/AndroidApplication.swf
X-Flash-Version: 10,2,152,22
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Cookie: _session_id=950dee7eca6732aa62b5f91876f66d15
Content-Length: 84
Connection: keep-alive

Does anyone have any insight into why Rails would generate a new session under those circumstances? It seems to be happening after my controller code executes, since I have the correct session information in the controller.

I'm busy trying to isolate the problem further, control the headers from within AIR, and so on. I've been working on this bug for almost a week. So any insight or suggestions from the community would be greatly appreciated.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

め可乐爱微笑 2024-10-27 08:32:51

只是猜测,但似乎您没有带来 Rails 为所有基于 POST 的请求生成的 CSRF 令牌:

http://guides.rubyonrails.org/security.html#cross-site-request-forgery-csrf

Only a guess, but it seems like you're not bringing across the CSRF token that Rails generates for all POST-based requests:

http://guides.rubyonrails.org/security.html#cross-site-request-forgery-csrf

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文