站长百科 | 数字化技能提升教程 数字化时代生存宝典
首页
数字化百科
电子书
▼
建站程序
开发
服务器
办公软件
开发教程
▼
服务器教程
软件使用教程
运营教程
热门电子书
▼
CSS教程
WordPress教程
导航
程序频道
推广频道
网赚频道
人物频道
网站程序
网页制作
云计算
服务器
CMS
论坛
网店
虚拟主机
cPanel
网址导航
WIKI使用导航
WIKI首页
热点词条
最新资讯
网站程序
站长人物
页面分类
使用帮助
编辑测试
创建条目
网站地图
站长百科导航
站长百科
主机侦探
IDCtalk云说
跨境电商导航
WordPress啦
站长专题
网站推广
网站程序
网站赚钱
虚拟主机
cPanel
网址导航专题
云计算
微博营销
虚拟主机管理系统
开放平台
WIKI程序与应用
美国十大主机
编辑“
Gallery Remote:Protocol
”(章节)
人物百科
|
营销百科
|
网赚百科
|
站长工具
|
网站程序
|
域名主机
|
互联网公司
|
分类索引
跳转至:
导航
、
搜索
警告:
您没有登录。如果您做出任意编辑,您的IP地址将会公开可见。如果您
登录
或
创建
一个账户,您的编辑将归属于您的用户名,且将享受其他好处。
反垃圾检查。
不要
加入这个!
=Introduction= This document describes version 2 of the Gallery remote application protocol, and its minor revisions. The "Gallery Remote" remote administration program is this protocol's ''raison d'être''. Version 1 of the protocol was tied very tightly to that application. It is clear that in addition to Gallery Remote users, there is a growing number of users that would like to query and control Gallery installations with their own programs. Version 2 adds some extra features but (hopefully) greater potential for other remote applications based on Gallery. If you would like to make suggestions for future work on the Gallery Remote protocol, please submit them to either of the authors. ==G2 support== The long-term plan for G2 remote access is to design a protocol based on SOAP or some other HTTP RPC protocol. However, as a stopgap, we have implemented the existing protocol 2 in G2, with some small differences. Because of G2-specific constraints, the format of the URLs is a bit different: * the base URL is <code><nowiki>http://www.example.com/g2_path/main.php</nowiki></code> * an additional URL parameter needs to always be added: <code>g2_controller=remote:GalleryRemote</code> * each parameter needs to be modified to <code>g2_form[<i>name</i>]=<i>value</i></code>. For example, on a login request, the <i>cmd</i> parameter would be passed as <code>g2_form[cmd]=login</code>. ** except in <code>add-item</code>, where <code>userfile</code> and <code>userfile_name</code> become <code>g2_userfile</code> and <code>g2_userfile_name</code> respectively * album "names" and image "names" are actually the unique identifier (an integer) of the object in G2, rather than an alphanumeric name * the authToken [G2 since 2.10] ===authToken=== Starting with G2.2 (svn r15234, protocol 2.10), a new security was put in place in order to defend against cross-site request forgery attacks. G2 expects all requests to have a new URL parameter, <code>g2_authToken</code>, which contains a string. The value of that string should be the value of the <code>auth_token</code> response element to the ''previous request''. This lets G2 make sure that a malicious script in another web page can't piggyback on the session that was created between the browser and G2, because the malicious code can't guess the authToken (it's not stored as a cookie). All protocol responses will contain this new <code>auth_token</code> field. Usually, it's safe to assume that the authToken doesn't change throughout the lifetime of a session. ==Overview== Gallery remote queries and sends information from a Gallery server through a protocol based on HTTP and form-data. The protocol leverages the same user authentication (and session cookies) as the web/HTML interface to the site. It is implemented in the PHP source file gallery_remote2.php (in G2, it's implemented by the <code>remote</code> module. Each query from client to server corresponds to one action. Multiple actions require multiple HTTP requests. The protocol is stateful and depends on the client supporting cookies. The client must provide login credentials for the session to be validated by sending a <code>[[#login|login]]</code> request before any other requests will succeed. Because the protocol has grown organically, and was developed over the course of many years by different people, it contains many syntactic inconsistencies (sometimes parameter names use dashes, sometimes underscores, sometimes camelhumps). We apologize for these. ==Conventions== In this document, all protocol text is denoted by a fixed-width font, like <code>login</code>. Value placeholders are additionally in italics, as in <code>status=<i>result-code</i></code>. Along with each parameter or return value, is specified the version of the protocol when this parameter was introduced. For parameters or return values that are only supported by G2, this is also noted. Optional parameters are indicated. '''Please note''' that the version numbers used by the Gallery 1 version of the protocol do not match the version numbers used by the Gallery 2 version of the protocol. [[#Appendix_B|Appendix B]] has a list of the major functional improvements, and the version they were introduced in G1 and G2. In general, parameters that are not supported in a given version of the protocol are just ignored. Conversely, client applications should ignore return values that they don't understand. ==Client-server interactions== All client-server interaction follows the standard HTTP model. The client initiates all interactions with a request. The server always responds with one response. The data format of each request is HTTP form-data key/value pairs. The data format of each response is plain text key/value pairs. Each request specifies a command value (and possibly some corresponding parameters) which determines the content of the response. Command-specific responses are defined in the context of each command below). In G1, the encoding used for the data is more or less unspecified, so it is recommended to use HTML entities to encode non-ASCII characters. In G2, however, UTF-8 is always used, so plain text should be used for all strings (no HTML entities or escaping, except the escaping necessary for the Java properties file format). ==Requests== Each request from the client is sent to the server through an HTTP POST. Parameters of the request are expressed as HTTP form data. Form data uses a key / value format referred to in the spec as "control-name / current value." Here we simply refer to key and value. Each request must specify a command (the <code>cmd</code> key). Depending on which command is specified, other key/value pairs are required in the form-data set (as parameters). Each request must specify a protocol version (the <code>protocol_version</code> key). The server's response to the <code>[[#login|login]]</code> command includes the version of the protocol it implements (with the server_version key). Protocol numbers obey the following convention: <code><i>maj</i>.<i>min</i></code> where <code><i>maj</i></code> is the major version number and <code><i>min</i></code> is the minor version number. The current major version number is 2. Protocol 1 is no longer supported. Each command is described in the Commands section below. After a brief description of the command, template form data appears and the contents of the server's response is described. ==Responses== After the client POSTs a request, the server sends a response to the client. The format of the response is a key/value format compatible with the Java "Properties" stream format. In a nutshell: lines beginning with a # character are ignored. The text before the first = character is the key. The remainder of the text after the = until the end-of-line character(s) is the value. Each response must begin with the text <code>#__GR2PROTO__<code>. Clients should ignore any text above this tag: it might be debug output from the server. Each response must contain at least the keys: <code>status</code> and <code>status_text</code>. The value associated with the status key is an integer status code (the codes are defined in [[#Appendix A|Appendix A]]. For example, if the server was able to complete the command in the client's request, the value of the status code will be <code>GR_STAT_SUCCESS</code>. The <code>status</code> key is definitive, yet the <code>status_text</code> may contain human-readable additional information (likely to be English language only). Otherwise, if the server was not able to successfully complete the request, the status will be a non-zero integer (see [[#Appendix A|Appendix A]]).
摘要:
请注意,您对站长百科的所有贡献都可能被其他贡献者编辑,修改或删除。如果您不希望您的文字被任意修改和再散布,请不要提交。
您同时也要向我们保证您所提交的内容是您自己所作,或得自一个不受版权保护或相似自由的来源(参阅
Wordpress-mediawiki:版权
的细节)。
未经许可,请勿提交受版权保护的作品!
取消
编辑帮助
(在新窗口中打开)