用于JavaScript的JSON API

用于JavaScript的JSON API - 处理会话数据服务器端，还是在浏览器中？(JSON API intended for JavaScript use - handle session data server side, or in browser?)

我正在构建一个使用JSON的API。 此API的主要用途是在浏览器中使用AJAX，但也可以在用户的​​PHP脚本等服务器端使用它。

我有两种方法可以做到这一点（我认为）：

构建API，使其使用HTTP标头设置会话cookie，并使用COOKIE['session_id'] （伪代码）检索所有数据以维护状态 构建API以便它返回session_id并允许用户的JavaScript代码为session_id设置自己的cookie

我总体上有点失落。 哪种方式更安全（CSRF等），开发人员易于理解，更容易进行服务器端更改，而无需告知用户必须更新其代码。

另外，您是否建议使用JSON-RPC规范，如果是这样，请不要使用其中一种方法更好地支持JSON-RPC？

任何帮助深表感谢。

I'm building an API that will use JSON. The primary use for this API will be AJAX in a browser but it may also be used server-side by user's PHP scripts, etc.

There are 2 ways I can do this (I think):

Build the API so that it uses HTTP headers to set a session cookie and retrieve all data for maintaining state by using the COOKIE['session_id'] (pseudo code) Build the API so that it returns session_id and allows the user's JavaScript code to set its own cookie for session_id

I'm a little lost in general. Which way will be more secure (CSRF, etc), easily understood by developers, easier to make server-side changes without telling users they have to update their code.

Also, do you recommend using JSON-RPC spec, and if so, do one of these methods better support JSON-RPC?

Any help is much appreciated.

最满意答案

我遇到了同样的问题（如何为基于JSON-RPC的Web服务基础架构进行会话）。 我最终使用了会话的URL参数。 我的推理：

使用cookie意味着cookie最终成为应用程序运行的基础。 我更喜欢完全禁用cookie并且仍然可以使用该应用程序的选项。 从非Web环境（例如，从本机Windows应用程序）处理JSON-RPC服务时，HTTP标头似乎可能会出现问题。 使用会话作为每个方法的第一个参数是我发现的简单丑陋的东西。

由于带有会话参数的URL仅用于调用Web服务方法，因此不会出现在浏览器的URL栏中，因此我认为以这种方式工作实际上不会产生安全隐患。 但是安全性是一件很棘手的事情，所以我相信有人会帮助纠正我。

I was faced with the same problem (how to do sessions for a JSON-RPC based web service infrastructure). I ended up using a URL parameter for the session. My reasoning:

Using cookies means cookies end up being fundamental to the operation of the app. I prefer the option of disabling cookies entirely and still having the app work. HTTP headers seemed like they could get problematic when addressing the JSON-RPC service from a non-web environment (e.g. from a native windows app). Using the session as the first argument to every method is something that I find just plain ugly.

Since the URL with the session parameter is only used to call web service methods, and therefore doesn't appear in the URL bar of the browser, I don't think there are actually security implications of working this way. But security is a tricky thing, so I'm sure someone will be along in a bit to correct me.