第二部分:Guzzle

前一篇博客中,我们学习了一下Composer这一PHP的类加载和依赖管理工具,并且利用这一工具下载了Guzzle。Guzzle是一个基于PHP的HTTP客户端库,极大的简化了对RESTfull web服务的调用过程。在本文中,我们将学习一些Guzzle的基本功能,并在这个基础上建立一套简陋的SDK。

入门

距离上次的Composer项目已经有一段时间了,让我们首先更新一下,获取最新的代码。首先编辑你的composer.json文件:

{
    "require": {
        "guzzlehttp/guzzle": "4.1.*"
    }
}

我们可以在composer.json文件所在目录执行composer update命令,更新到最新的guzzle代码。如果你是重新开始,那么应该运行的是composer install命令。

在前一篇博文中,我提供了一些基础的代码可以放在index.php文件中:

第一部分:Composer

译者:强烈推荐Composer中文网

Drupal 8带来很多变化,这变化不仅体现在技术和架构上,更体现在社区生态上。目前我们还没能完全体会这些变化造成的影响,但是我相信随着时间的推移,Drupal 8的转型将会为社区带来巨大的益处。众多改变之中,比较醒目的一项就是引入外部代码的决定。对比之前的版本的做法,这是一个令人震惊的戏剧性转变。本系列文章会尝试介绍这一变化。

Drupal不是唯一发生变化的系统,PHPBB、EZPublish甚至一些非产品化的PHP系统都开始进行这方面的尝试,这一现象也被称为“PHP复兴”。这一复兴的原动力是互操作性,而互操作性建立在以下基础之上:

Drupal 真的难?

Tags: 

每隔一段时间,在Drupal相关的论坛、QQ群、Twitter什么的上面就会看到"Drupal好难"、“学习曲线陡峭”、“Drupal Sucks”等类似的车轱辘话,以及那副倒霉的乱葬岗图。

Drupal 真的这么难?

Drupal作为一个框架和平台的混合体,在项目实施上,的确有些不错的优点。但是单就复杂度来说,不管是框架上,例如大行其道的SSH,远古时代的MFC;还是平台上,例如SAP、WebSphere之流,我的感觉是,Drupal的复杂度还并不突出,甚至颇有不如。

为什么难声一片?

核心方向摇摆不定

个人浅见,根本原因在于Drupal的核心颇有些摇摆不定。Drupal 7 时曾明确提出了Content Management Framework的概念。

而在Drupal 8的发育过程中,多数时间夸夸其谈的题目主要在数字化体验、移动支持等功能层面的内容,以及Views入~~常~~核的“可喜”变化 —— 很明显,社区对于framework并不买账。

对话

A: 据说你们Drupal只能连一个数据库?

B: 框架自用的一般只连一个,读写分离什么的也会做些切换,至于外部数据库,那就随意了。

A: 我这有个需要界面的需求,你看让你的人直接PHP连上我们这边Oracle数据库,一起做了吧。

B: 那不行,我可不想给你编译环境去,PHP的OCI我记得可是臭名昭著。

A: 那你觉得应该怎么办?

B: 简单,你们做服务,PHP做界面。

A: 很小的东西,不用这么麻烦吧?

B: 我不想两组应用挂同一个数据库,更不想两组人挂在同一个数据库上,一定会出乱子的。

A: 那我写个服务,让你们发表发CRUD操作,我给你执行吧?这样以后操作也方便。

B: 烟囱可是大忌,用Java不就是要实现业务逻辑的么?你也说了东西小啊?

A: 我知道你要求高,不过项目这么紧,需求这么小,就不用这么严格了吧?

B: 完美是做不到的,但是总不能让小弟们从来不想一下什么是完美吧。

Drupal Services模块入门教程

Services模块为Drupal站点提供了实现Web服务的能力。

Services很流行,可以同REST, XMLRPC, JSON以及SOAP协同工作。

然而,在上星期的一次培训中,当被问到Services的问题时,我意识到,问题产生的原因在于——这个模块几乎没有清晰的可用的文档。

所以我决定写一篇Services模块的入门教程。

下面就是利用Services为Drupal站点建立REST API的五个步骤:

1. 安装

基础的REST API需要三个模块的支持:

Drupal工作流概览

现在,一个商业公司如果发布了静态或者过时的Web内容,会给人造成不合时宜、步履蹒跚的印象,因此,各种机构都体会到了要频繁创作Web内容,更新现有内容以及同在线用户分享文档的持续增长的压力。

内容维护的压力使得内容采编人员的编制随之增长,人数的增长就要求组织利用Drupal这样的内容管理系统,来开发并执行一套内容采编流程。最主要的挑战是如何为众多的采编人员提供一个环境,这一环境能够在不影响现有的内容,也不降低安全性的前提下,让采编人员能够发布内容。在此基础上,还要建立品牌标准并提供质量保障。这一过程涉及到的内容编写和审批的职责:

编辑/审批

  • 审查:是否有淫秽或者其他的负面内容?

  • 可读性:有没有语法、格式拼写或者其他类似问题?

  • 准确性:内容是否真实?其中涉及到的统计数字以及事实是否需要再次确认?

  • 品牌:是否正确使用公司的字体、颜色以及图片?内容、语气以及技术术语是否符合公司的标准?

  • 版权:公司是否有权发布这些内容、图像以及外部文档?所有的来源引用是否都有标明?

作者

  • 提供能够准确体现公司信息的内容。

Drupal 基础安全实战

最近翻译了一篇老外写的全站SSL介绍,感觉水得一塌糊涂,恰好前一段时间被合作方的安全团队在安全方面骚扰很久,涉及的问题范围较广,也比较全面,这里做个总结,也给大家一个参考。

下面行文主要从Issues List里面提取,顺序上可能稍显跳跃,因为是工程案例,所以偏重于见招拆招的解决问题,而较少提供问题的剖析,不过尽量会提供引文供读者延伸阅读。

SSLv3 Enabled

Openssl对于ssl poodle问题的说明

Digital Ocean对这个问题的说明和对策

Apache Server的配置:

    SSLProtocol all -SSLv3 -SSLv2

Nginx Server的配置

Drupal静态缓存

Drupal的伸缩性是存在的,而且非常强大。当我们问别人对Drupal的看法时候,多数时间得到的答案是:据说那东西很慢。在我的工作中见到过很多性能低下的Drupal站点,缓存是其中的重要原因。即使是基础的Drupal安装,其中也包含了一套针对数据表的多层缓存,不幸的是,这一缓存体系很容易被开发者破坏。

阻碍缓存的最大原因可能就是在自定义模块中错过了利用缓存提升性能的机会。把计算后的结果保存在PHP变量中,接下来的调用过程可能会得到成百上千倍的性能提升。要使用这一技巧只需要很小成本:如果一个结果已经得出,就返回这一结果;否则,运算得到结果之后,首先保存结果,然后才返回。

Drupal SQL注入漏洞后的一周——黑客教了我们什么?

在10月15日,黑客们忙着跟进一个问题:如何利用Drupal 7的SA-CORE-2014--005漏洞进行SQL注入。一个星期过去了,攻击者们仍然在持续忙碌。Moshe Weizman发文解释了我们如何在这一缺陷暴露的情况下保护客户的网站。在本文中,我们会看看近期对Acquia Cloud中针对SQL注入缺陷的攻击的来龙去脉。

本文的数据基于Acquia Cloud上托管的几万个网站中产出的大量日志,并经过了内部工具的整理和分析。所有本文中提及的时间都是美国东部标准时间。我们目前认为Acquia Cloud中的站点尚未被击破,所以我们只会描述一些入侵的尝试,不过外边的Drupal站点来说,运气可能就没那么好了。如果在阅读本文时你还没有对你的站点进行修补,也许下一分钟你的站点就已经被侵入了。

模式1:docroot中的后门

攻击次数:7785

页面