贴吧图片
0

很多用户反映,希望重新打开浏览器,进入本网站后应该可以保持登录状态。

这个问题本站今天已经解决,但需要大家清除一下浏览器的历史记录和cookie,然后在登录时选择“保持登录状态”,即可不用反复再登录了。

谢谢!

更新时间:04/09/2014
贴吧图片
4

如题!学生无法创建项目!!!

最后回复:leewei
04/09/2014
更新时间:04/09/2014
贴吧图片
2

创建课程,填完表之后,提交,系统报错,貌似正在维护?

何时可以创建?

谢谢!

最后回复:leewei
04/04/2014
更新时间:04/04/2014
贴吧图片
2

目前,交作业和作业列表的页面是分开的。能否允许学生直接在作业列表下直接交作业?

最后回复:尹刚
04/02/2014
更新时间:04/02/2014
贴吧图片
2

目前,作业按照发布时间从新到旧,自上而下排列。我建议应当允许用户调整排列顺序或者更换排列规则。我先发布了第三周作业的第一部分,而后发布了第四周的作业,而后发布了第三周作业的第二部分,结果呢,第三周的两部分作业无法调整在一起。

最后回复:尹刚
04/02/2014
更新时间:04/02/2014
贴吧图片
3

http://segmentfault.com/

从界面上看,仿StackOverflow做的,目前声称有10万个开发者。

最后回复:尹刚
04/02/2014
更新时间:04/02/2014
贴吧图片
1

今天打开OSChina主页,页面先是变模糊,然后弹出对话框愚弄了用户一下,一个很有意思的愚人节礼物^_^

其中可以让网页变模糊的代码已经共享了,转来与大家分享

01 <![if !IE]>
02 <script>   
03 /*
04 * by moli
05 */
06 $(document).ready(function(){
07   if(document.cookie.indexOf("lu=") == -1 ){
08     // 延时2秒
09     setTimeout("jQuery.mxblur.interID = setInterval('jQuery.mxblur.begin()', 5)", 1500);
10   }
11 });
12  
13 $.mxblur = {
14     interID : null,
15     num: 0.01,
16     begin : function() {
17         jQuery.mxblur.blur( jQuery.mxblur.num );
18         if(jQuery.mxblur.num > 3) {
19             jQuery.mxblur.num = 0;
20           if(confirm("少年!是不是代码写多了?眼睛模糊了?")) {
21              alert("太累啦,就该歇歇啦,愚人节快乐:)");
22              clearInterval(jQuery.mxblur.interID );
23              jQuery.mxblur.blur(0);
24              document.cookie = "lu=lu";
25           }
26         }
27         jQuery.mxblur.num = jQuery.mxblur.num  + 1 /100;
28     },
29     blur : function() {
30         $("body").css("-webkit-filter","blur("+$.mxblur.num+"px)");
31         $("body").css("-moz-filter","blur("+$.mxblur.num+"px)");
32         $("body").css("-o-filter","blur("+$.mxblur.num+"px)");
33         $("body").css("-ms-filter","blur("+$.mxblur.num+"px)");
34         $("body").css("filter","blur("+$.mxblur.num+"px)");
35         $("body").css("filter","url(blur.svg#"+ $.mxblur.num.toFixed(1) +")");
36     }
37 }
38 </script>
39 <![endif]>
最后回复:谭显波
04/01/2014
更新时间:04/01/2014
贴吧图片
0

链接挖掘(Linking Mining)是数据挖掘在社交网络中的一个应用。

LM将社交网络看成由若干实体构成,实体间的交互通过链接完成,对彼此链接信息的挖掘构成链接挖掘。

这份PPT以几种常见的挖掘模式为依据展开介绍,可以作为初步接触LM的入门材料。

附PPT大纲:

基本概念

数据表示

基于链接的节点排序(Link-Based Object Ranking)
基于链接的节点分类(Link-Based Object Classification)
节点聚类(Object Clustering)
链接预测(Link Prediction)
子图发现(Subgraph Discovery)
图分类(Graph Classification)

更新时间:03/31/2014
贴吧图片
0

能否实现个人标签的删除和修改的功能?

但只能修改自己管理的对象的标签。。。

更新时间:03/31/2014
贴吧图片
2

问题:项目-->缺陷-->新建问题 ,点击新建问题报错。

最后回复:尹刚
03/28/2014
更新时间:03/28/2014
贴吧图片
4

昨天注册了,但是无法加入课程,点击“加入课程”后,页面中间显示“加载中”,但一会就消失了。无法正常加入,请问这是为什么?

最后回复:谭显波
03/28/2014
更新时间:03/28/2014
贴吧图片
2

起步教程,适合没接触过SOF的读者初步了解。

后续会持续跟进相关研究

最后回复:尹刚
03/27/2014
更新时间:03/27/2014
贴吧图片
1

提个需求:

用户在上传附件的时候,可否直接把文档名赋值给标题?用户共享的文档标题很有可能就是帖子的主题,如果不是,用户选中再修改就是。

网易的邮箱很早就已经实现了,请大家考虑!

最后回复:尹刚
03/26/2014
更新时间:03/26/2014
贴吧图片
2

我们以主干中已修复的Rails 3问题来开始。修复这些问题时,Rails团队功不可没,但是仍然值得注意,因为很多程序将在Rails 2和3上运行多年。

1. 通过#match路由泄漏进行CSRF攻击

这里有一个例子,直接来自Rails 3生成的config/routes.rb文件:

1 WebStore::Application.routes.draw do
2   # Sample of named route:
3   match 'products/:id/purchase' => 'catalog#purchase',
4     :as => :purchase
5   # This route can be invoked with
6   # purchase_url(:id => product.id)
7 end

这样做的结果,对于任何HTTP方法(GET,POST等),都将/products/:id/purchases路由到CatelogController#purchase方法。问题是,Rails的跨站请求伪造(CSRF)防护对GET请求无效。从执行CSRF防护的方法中看到:

1 def verified_request?
2   !protect_against_forgery? ||
3   request.get? ||
4   form_authenticity_token ==
5     params[request_forgery_protection_token] ||
6   form_authenticity_token ==
7     request.headers['X-CSRF-Token']
8 end

第二行跳过了CSRF检查:意味着如果request.get?为true,请求被认为是“verified”,CSRF检查被跳过。实际上,Rails源代码里,在该方法的前面就有注释:

Get应该是安全和无副作用的。

Lax

Lax
翻译于 11个月前

1人顶

 

在程序里,你可以一直使用POST方法来访问/products/:id/purchase。但是因为路由器也允许GET请求,对于任何由#match路由的方法,攻击者都可以绕过CSRF保护。如果你的程序使用旧的通配符路由(已经不推荐),CSRF保护完全无效。

最佳实践: 对于不安全行为,不要使用GET。不要使用#match来添加路由(而应该用#post,#put等代替)。确保没有通配符路由。

解决方法: 现在,如果使用#match来添加路由,Rails需要你指定HTTP方法或via: :all。自动生成的config/routes.rb不再包含注释掉的#match路由。(通配符路由也被删除。)

 

2. 正则表达式中进行格式验证的锚点

观察下面的验证代码:

1 validates_format_of :name, with: /^[a-z ]+$/i

这是一个不明显的bug。开发者可能想强制要求整个name属性仅仅包含字母和空格。然而,它仅仅强制name属性至少一行由字母和空格组成。再看几个正则表达式匹配的例子来澄清一下:

1 >> /^[a-z ]+$/i =~ "Joe User"
2 => 0 # Match
3  
4 >> /^[a-z ]+$/i =~ " '); -- foo"
5 => nil # No match
6  
7 >> /^[a-z ]+$/i =~ "a\n '); -- foo"
8 => 0 # Match
开发者其实应该用\A(字符串起始)和\z(字符串结束)锚点来代替^(行起始)和$(行结束)。正确的代码应该为:
1 validates_format_of :name, with: /\A[a-z ]+\z/i

你可能会说开发者错了,而你做对了。然而,正则表达式锚点的行为并不显而易见,尤其对于没考虑多行输入的开发者。(也许该属性仅仅漏出一个文本输入区input field,而不是文本框textararea)

Rails在保护开发者方面考虑的不错,这也是在Rails 4中所做到的。

最佳实践:在任何情况下,使用\A和\z作为正则表达式锚点,代替^和$。

修复方法: Rails 4为validates_format_of引入了支持多行的选项。如果你的正则表达式使用^和$而不是\A和\z,且不传递multiline: true,则Rails将抛出异常。这是创建安全默认行为的例子,且仍然在必要的场合提供控制选项来覆盖它。

 

3. 点击劫持

点击劫持或“UI纠正攻击”包括在一个可视框架内渲染目标站点,当受害者点击时就能欺骗他采取意想不到的行动。如果一个站点易受点击劫持攻击,一个攻击者可能欺骗用户采取非预期的行动,像一键购买,在Twitter上关注某人或改变他们的隐私设置。

为了抵御点击劫持攻击,一个站点必须防止自己被呈现在一个框架或它不能控制的iframe中。老的浏览器需要丑陋的“框架破坏”JavaScripts,而现代的浏览器支持可以指示浏览器是否应该允许该网站被加框的X-Frame-Options HTTP头。这个头很容易被包含,并且不可能破坏大部分网站,因此Rails应该默认包含了它。

最佳实践: 通过Twitter使用安全头RubyGem添加一个值为SAMEORIGIN或DENY的X-Fram-Options头。

修复方法: Rails4默认将X-Frame-Options头的值设为SAMEORIGIN。

 

1 X-Frame-Options: SAMEORIGIN
这告诉浏览器你的应用程序只能被源自相同域的页面加框。 
 

 

4. 用户可读回话

默认的Rails 3会话存储使用署名的、未加密的cookies。虽然这可以包含会话不被篡改,对于攻击者来说,解码一个会话cookie的内容是轻而易举的事:

01 session_cookie = <<-STR.strip.gsub(/\n/, '')
02 BAh7CEkiD3Nlc3Npb25faWQGOgZFRkkiJTkwYThmZmQ3Zm
03 dAY7AEZJIgtzZWtyaXQGO…--4c50026d340abf222…
04 STR
05  
06 Marshal.load(Base64.decode64(session_cookie.split("--")[0]))
07 # => {
08 #   "session_id"  => "90a8f...",
09 #   "_csrf_token" => "iUoXA...",
10 #   "secret"      => "sekrit"
11 # }

在一个会话中存储任何敏感信息都是不安全的。希望这是众所周知的,但即使一个用户的会话不包含敏感信息,也还是会带来奉献。通过解码会话数据,一个攻击者能够获取一些关于程序的内部结构的、有利于攻击的信息。例如,他可能知道系统用的是什么认证(Authlogic,Devise等待)。

虽然不会创建一个自身的弱点,但它可以帮助攻击者。任何有关应用程序如何工作的信息都可用来磨练功绩,有时也用来避免触发那些会给开发人员预警攻击正在进行的异常或绊网。

用户可读会话违反最小特权原则,因为即使会话数据必须传给访问者的浏览器,他也不需要能够读取这些数据。

最佳实践: 不要将任何你不想让攻击者访问的信息放到一个会话中。

修复方法: Rails 4将默认会话存储改为加密的。在没有解密密钥的情况下,用户在客户端无法解码会话的内容。

 

未解决的问题

这篇文章剩下的部分会讲一下在出版的时候Rails还存在的的安全风险。希望最少这里的一些会被修复,同时我将会在修复了的情况下更新这篇文章。

1. VerboseServerHeaders

默认的Rails服务器是WEBrick(部分是Ruby标准库),虽然它很少在产品模式下运行WEBrick。作为默认的选择,WEBrick返回在每个HTTP回复一个verboseServerHeader。

1 HTTP/1.1 200 OK
2 # …
3 Server: WEBrick/1.3.1 (Ruby/1.9.3/2012-04-20)
看下WEBrick的源代码,你可以看到头部是由一些关键性的信息组成: 
1 "WEBrick/#{WEBrick::VERSION} " +
2 "(Ruby/#{RUBY_VERSION}/#{RUBY_RELEASE_DATE})",

这暴露的WEBrick的版本,同时也包括正在运行的特定的Ruby的补丁级别(因为发布日期与补丁级别匹配)。使用这些信息,spray和prey扫描者更有效地针对你的服务器,同时可以定制他们的攻击让其变得更有效了。

最好的实践: 避免在产品模式运行WEBrick。有其他更好的服务器,如Passenger,Unicorn,Thin和Puma。

修复: 虽然这个问题是起源于WEBrick的源代码,Rails应该配置WEBrick来使用更小的verboseServerHeader。简单点就“Ruby”似乎更好。

 

2. 绑定到0.0.0.0

如果你启动一个Rails服务器,你会看到一些像下面的东西:

1 $ ./script/rails server -e production
2 => Booting WEBrick
3 => Rails 3.2.12 application starting in production on http://0.0.0.0:3000

Rails在绑定到0.0.0.0(所以网卡)而不是127.0.0.1(仅本地网卡)。这会在开发模式和产品模式的上下文上都会产生安全风险。

在开发模式,Rails并不安全(举例来说,它渲染诊断500个页面)。此外,开发者可能加载一个混合了产品数据和测试数据的东西(例如用户名:admin/密码:admin)。在三藩市的咖啡店里扫描web服务器的3000端口将可能收到很好的目标。

 

在生产环境下,Rails必须通过代理服务器来运行。如果没有代理,IP欺骗攻击就会时常发生。如果Rails绑定了0.0.0.0,攻击者就可以轻松绕过代理服务器,直接攻击Rails服务器。

所以,绑定到127.0.0.1比默认的0.0.0.0会更安全。

最佳实践:保证生产环境仲的web服务器进程绑定了最小的一组接口。不要为了调试,而把生产环境数据导入到你的手提电脑。如果你必须这样做,尽可能少的导入数据,并且当它没用的时候立刻删除。

修复:Rails已经提供了一个绑定选项来修改服务器监听的IP地址。我们必须把默认的0.0.0.0修改为127.0.0.1。开发人员如果需要修改生产环境的绑定接口,可以通过修改部署配置来实现。

 

3. 记录Secret Tokens的版本

每一个Rails app都会获取一个很长,而且是随机生成的secret token,当使用rails new的时候,它会被生成并保存在config/initializers/secret_token.rb。里面的内容类似这样:

1 WebStore::Application.config.secret_token = '4f06a7a…72489780f'

因为rails自动创建secret token,所以很多开发者会忽略掉它。但是这个secret token就像是你的应用的管理员钥匙。如果你拥有了secret token,那样伪造会话和提升权限就会变得很容易。这是其中一个十分重要而且敏感的数据需要去保护的。加密是保护你的钥匙的最佳办法。

但是很不幸,rails并不能很好的处理这些secret token。secret_token.rb文件会被加入到版本控制当中,复制到GitHub,CI服务器和每一个开发人员的电脑。

enixyu

enixyu
翻译于 11个月前

0人顶

顶 翻译的不错哦!

最佳实践:在不同的环境中使用不同secret token。在应用中插入ENV变量就可以实现这个目的。另外一个替代方法是,在部署过程中把secret token作为符号链接。

修复:至少,rails必须通过.gitignore来忽略config/initializers/secret_token.rb文件。开发人员在部署的时候,用一个符号链接来替代生产环境的token,或者把初始化器转变为使用ENV 变量来初始化(例如Heroku)

我将会进一步提出rails创建一个保存serect token的机制方案。我们有大量的库提供安装指引如何把secret token加入到初始化器中,但是这并不是一个好的实践。同时,至少还有俩个解决方案来处理这个问题:ENV变量和初始化器的符号链接。

rails提供一个简单的API给开发人员来管理secret token,而且后台还是可插拔的(就像缓存和会话存储)。

 

4. 在SQL语句里记录值

Rails提供的config.filter_paramters是阻止累计在产品日志文件的敏感信息的有用方法,例如密码。但它不影响记录在SQL语句的值。

01 Started POST "/users" for 127.0.0.1 at 2013-03-12 14:26:28 -0400
02 Processing by UsersController#create as HTML
03   Parameters: {"utf8"=>"✓œ“""authenticity_token"=>"...",
04   "user"=>{"name"=>"Name""password"=>"[FILTERED]"}, "commit"=>"Create User"}
05   SQL (7.2ms)  INSERT INTO "users" ("created_at""name""password_digest",
06   "updated_at"VALUES (?, ?, ?, ?)  [["created_at",
07   Tue, 12 Mar 2013 18:26:28 UTC +00:00], ["name""Name"], ["password_digest",
08   "$2a$10$r/XGSY9zJr62IpedC1m4Jes8slRRNn8tkikn5.0kE2izKNMlPsqvC"], ["updated_at",

 

09   Tue, 12 Mar 2013 18:26:28 UTC +00:00]]
10 Completed 302 Found in 91ms (ActiveRecord: 8.8ms)
Rails在产品模式的默认日志级别(info)不会记录SQL语句。这里的防线是有时候开发者会在调试的时候增加日志级别。在这期间,应用程序会写入敏感数据到日志文件,然后在服务器上长时间持久化。一个攻击者获得阅读服务器上文件权限能够简单地通过grep来找到数据。


 

最佳实践: 要对产品级日志记录了什么保持清醒。如果你临时增加日志级别,记录下敏感数据,一旦它不再需要了请立刻删除那些数据。

修复:Rails能改变config.filter_parameters成为config.filter_logs的样子,并且将其同时应用到参数和SQL语句。它可能不能在所有情形下正确的过滤SQL语句(因为它需要一个SQL解析器),但对于标准的插入与更新可能有80/20的解决方案。

作为一个备选方案,如果它包含有对过滤数值的引用,Rails可以编辑整个SQL语句(例如,编辑所有包含“password”的语句),至少在产品模式是如此。

 

5. 离线重定向

许多应用包含一个action控制器,它根据上下文将用户带到一个不同地址。最常见的例子是Session控制器,引导最近验证的用户到他们想到的目的地址,或者引导到一个默认的目的地址:

01 class SignupsController < ApplicationController
02   def create
03     # ...
04     if params[:destination].present?
05       redirect_to params[:destination]
06     else
07       redirect_to dashboard_path
08     end
09   end
10 end

这引起了风险,攻击者可以创建一个URL,导致在信任用户登陆以后被引导到恶意网站:

1 https://example.com/sessions/new?destination=http://evil.com/

未验证的重定向可以被用作钓鱼,或者摧毁用户对你的信任,因为看起来是你带他们到一个恶意网站的。即使一个警惕的用户,在他们第一次页面加载以后,也可能不会检查URL地址栏来确认没有被钓鱼。这个问题非常严重,以致它被加入了最新一版的OWASP 十大应用安全威胁。

 

最佳实践:通过一个hash#转向时,使用选项 only_path:true 去限制转向到当前站点。

1 redirect_to params.merge(only_path: true)
当通过 字符串时,你能解析它为一个路径。

 

1 redirect_to URI.parse(params[:destination]).path<span style="font-size:10pt;line-height:1.5;font-family:'sans serif', tahoma, verdana, helvetica;"></span>

修复方法:默认情况下,Rails应该只允许转向同一域名或在白名单上的域名。在少数情况下,外部转向的地方是有计划的。开发者应该要求通过anexternal:true选项到redirect_to 按顺序去决定加入更多危险的行为。

 

 

6. 利用link_to的跨站脚本 (XSS) 

许多开发者没有意识到link_to助手的HREF属性可以被用来注入JavaScript脚本。这里是一个不安全代码的例子:

1 <%= link_to "Homepage", user.homepage_url %>

假设用户可以通过更新他们的注册信息修改homepage_url的值,这就引起了XSS风险。像这样:

1 user.homepage_url = "javascript:alert('hello')"

将会生成这个HTML:

1 <a href="javascript:alert('hello')">Homepage</a>

点击此链接将会执行攻击者提供的脚本。Rails的XSS保护不能阻止它。在社区转移到低调的JavaScript技术以前,这曾经是必要而且常见的,但现在成为一个残留的弱点。

最佳实践: 避免在HREF中使用不信任的输入。当你必须允许用户控制HREF时,先将输入通过URI.parse转换,并且清醒的检查协议与主机地址。

修复: Rails 应该默认在link_to助手中只允许目录,HTTP, HTTPS 和mailto:href 值。开发者应该通过传入link_to助手选项,选择进入不安全的行为,或者只是简单的link_to不支持这些,而开发者可以手工修改链接。

 

 

 

7. SQL注入

Rails做了个相当好的工作来阻止常见的SQL注入(SQLi)攻击,所以开发者会认为Rails是免疫SQLi的,并不是这样的。设想一个开发者需要基于参数拉取订单表的小计或者总计。他们可能这样写:

1 Order.pluck(params[:column])
这样做是不安全的。明显地,用户能够纂改应用程序来获取订单表上他们想要的的任何列数据。然而,一些不明显的东西是攻击者也能够拉取其他表值。例如: 
1 params[:column] = "password FROM users--"
2 Order.pluck(params[:column])
会变成:
1 SELECT password FROM users-- FROM "orders"
类似的,column_name属性在#calculate上实际是能接受任意的SQL的: 
1 params[:column] = "age) FROM users WHERE name = 'Bob'; --"
2 Order.calculate(:sum, params[:column])
会变成:
1 SELECT SUM(age) FROM users WHERE name 'Bob'--) AS sum_id FROM "orders"
控制#calculate方法的column_name属性允许攻击者从任意列或者任意表中拉取指定的值。
 

Rails-SQLi.org 详细讲述哪些ActiveRecord方法和选项允许使用SQL,而且提供例子说明它们是会遭到什么样的攻击。

最佳实践:了解你使用的APIs,同时要知道它们在什么情况下会允许超乎你预期的危险的操作,还有接受输入的白名单。

修复:很难找到解决所有问题的方案,因为不同的环境有不同的解决方案。通常,ActiveRecord APIs只允许经常使用的SQL片段,方法column_name的参数一般只接受列名。如果开发者想自己控制的更多,需要使用其他APIs。

点击Justin Collins的Twitter关于编写rails-sqli.org的信息,了解更多详情。

 

8. YAML 反序列化

就如大多数ruby开发人员在一月所学到的,使用YAML反序列化不信任的数据会带来安全隐患。网上已经有很多关于使用YAML的攻击的文章,所以我不会在这里阐述了,但是总的来说,如果攻击者可以入侵YAML,它们就可以随意的在服务器上运行代码。我们的应用无需做任何事情,只需有序的载入YAML,就会变得脆弱不堪。

虽然rails已经打了补丁,来避免转换的YAML通过HTTP请求发送到服务器。但是仍使用YAML作为#serialize功能和#store功能的默认的序列化格式,以下是存在风险的代码:

1 class User < ActiveRecord::Base
2   # ...
3   serialize :preferences
4  
5   store :theme, accessors: [ :color:bgcolor ]
6 end
大多数rails开发人员不会喜欢把随意的ruby代码保存在数据库,并且在读取记录后来解释运行它们,但是,这其实就等价于使用YAML反序列化的后果。当存储的数据不包含随意的ruby对象的时候,它就违反了最小特权原则。这个允许在数据库里面保存数据的漏洞,最终会导致整个服务器被攻击者控制。
 

尤其当自认为YAML看起来起来安全时,实际上很危险。YAML格式是在远程代码执行漏洞爆发前,由数百名熟练的开发者所确定的。然而如今他是Ruby社区的重点之一,Rails的新开发者显然不会再经历YAML远程攻击之祸。

最佳实践:使用JSOM序列化格式而不是YAML序列化

1 class User < ActiveRecord::Base
2   serialize :preferencesJSON
3   store :theme, accessors: [ :color:bgcolor ], coder: JSON
4 end

修复:Rails应该改变默认序列化格式,从YAML转到JSON。YAML应该作为Gem中的一个选择。

 

9. 批量赋值

Rails 4改用strong_parameters方式来处理批量赋值的漏洞,代替attr_accessible。params对象现在是ActionController::Parameters的实例。strong_parameters工作的方式是检查那个Parameters实例为“允许的”——开发者指定了哪个键(及类型)是可接受的。

总之这是一个积极的变化,却引入了attr_accessible体系中没有的新攻击方式。看下面的代码:

1 params = { user: { admin: true }.to_json }
2 # => {:user=>"{\"admin\":true}"}
3  
4 @user = User.new(JSON.parse(params[:user]))

JSON.parse返回一个常规的Ruby Hash,而不是ActionController::Parameters的实例。用了strong_parameters,默认行为是允许Hash实例通过批量赋值来设置任何属性。同样的问题发生在sinatra,在Sinatra程序中通过params访问ActiveRecord模型时——Sinatra不会把这个Hash包装为ActionController::Parameters实例。

 

最佳实践: 当使用ActiveRecord模型和其它web框架时(或从缓存、队列中反序列化数据时),尽可能使用Rails自带的解析。将输入数据包装到ActionController::Parameters,这样strong_parameters可以生效。

修复方式: 还不明确什么是最好的处理方式。Rails可以重写反序列化方法,比如JSON.parse,返回ActionController::Parameters实例,但这相对有侵入性且可能导致兼容问题。

相关的开发者可以在敏感区域(比如User#admin)结合采用strong_parameters和attr_accessible来得到额外的保护,但对于多数情况可能矫枉过正。这只是一个需要心中有数的问题,期待能尽快解决。

最后回复:尹刚
03/24/2014
更新时间:03/24/2014
贴吧图片
0

众所周知,万达是中国最大的商业地产公司,万达老板王健林是中国首富,过去几年一直都是顺风顺水。不过,老冀觉得,万达即将面临“成长的烦恼”:随着中国人口红利的消失,房地产行业的增长将会放缓。因此,我们看到最近几年万达开始发力文化产业,不仅在各地的万达广场中大规模兴建万达影院,还以26亿美元收购了美国第二大影院院线AMC。此外,万达还准备建设一大批文化主题广场。老冀认为,万达之所以这么做,都是为了在房地产之外再造一个未来的支柱产业。

在此之前,万达集团已经涉足零售业,成立了万达百货,但是做得并不好。万达的年会报告披露,2013年万达百货的收入是154.9亿元,只完成了计划的91%,这还是下调之后的计划。目前,万达百货仍持续亏损。

目前,万达集团旗下有商业地产、酒店、文化旅游和百货四大产业,商业地产仍然占大头,是典型的“收租模式”:万达在城市核心地带找好一块地,盖好房子然后找商家来租,万达每年收租金。这种“收租模式”不接触最终消费者,也不怎么关心商家的经营状况,反正这家走了再找另一家就是了。

而万达未来重点发展的几大产业的商业模式则与商业地产有着很大的不同,无论是酒店、主题公园、电影院线还是百货,其实都需要持续经营消费者。可是,怎样才能将这几块新业务串起来,形成合力呢?互联网也许是个很好的工具。老冀认为,这也许才是王健林执意要做电商的理由,至于说是因为跟马云打赌才做的,恐怕更多的是个烟雾弹。

万达电商从2012年5月开始组建,万达也亮出了土豪本色,花了200万年薪招总经理,100万年薪招高管。据说,几乎所有知名的电商高管都被万达的猎头骚扰过一遍,以至于没接到万达电话的,都不好意思说自己是搞电商的。

2012年12月,曾担任谷歌总部电子商务技术部经理、阿里巴巴国际交易技术资深总监的龚义涛就任那个年薪200万的万达电商总经理。此外,一大批来自阿里、谷歌等互联网公司的高管纷纷加盟万达电商。

问题是这波人都没做过线下业务,对万达独特的商业模式也是不甚了解。老冀觉得,未来实物经济与虚拟经济肯定会结合得越来越紧密。因此,互联网人一定要谦虚谨慎,杜绝“互联网沙文主义”,不要觉得动动鼠标、倒腾点流量就能搞定一切。

而实际上,这波互联网人就是犯了这个错误。他们提了很多套方案,不过都是些建个网站、做个移动App这样的纯互联网思路,当然一一被英明的王老板给否决了。一直折腾到2013年八九月份,他们仍然没有拿出一个适合万达的电商方案。结果,军人出身的王老板一生气,干脆派上了自己的“近卫军”,让万达IT部门接管了万达电商。据老冀了解,此后这波互联网人大多离开了万达。

在房地产行业,万达的IT系统是公认做得最好的,王老板只需要坐在办公室里动动鼠标,万达的所有大事小情就能够尽收眼里。因此,万达的IT部门是很强的,有着400多人的团队,万达集团的CIO朱战备也是很厉害的。老冀见过朱总几次,感觉他是个对公司业务和IT系统都很精通的人才,而且绝对务实。由于朱总过去曾经在外资企业上海贝尔阿尔卡特担任过CIO,喝过洋墨水,那些高大上的国外IT厂商想用些似是而非的新概念去忽悠他,绝对没门!在这里老冀也给传统企业的老板提个建议:当你准备开拓新业务的时候,与其从外边找不太靠谱的职业经理人,倒不如从内部找靠谱的部下。如果感觉CIO很靠谱,直接用CIO去做新业务肯定没错,因为这个CIO必然是既了解公司的业务,又熟悉互联网的大趋势,还懂一些技术,做新业务最合适。

务实的朱总带着一帮人开始重新研究万达的电商要怎么搞,结论很快就出来了:万达做B2C电商肯定没戏!一个是做B2C需要巨大的投入,而且由于天猫和京东已经建立起了遥遥领先的优势,你肯定赶不上。事实也是如此,苏宁在B2C上的决心不可谓不大,投入的资源不可谓不多,但是到了2013年年底一盘点,苏宁易购与京东的差距反而有拉大的趋势。

万达电商的新团队接着分析,如果不做B2C,万达又能做什么呢?这个还得看万达有什么。目前万达在全国有85家万达广场,2014年开到120家,2015年140家。每家万达广场每年的访问人数有2000万,一年就有超过20亿人次的流量,绝对能够赶超国内任何一家中型B2C电商的流量!而且,这些线下流量的客单价、转化率要比线上的B2C电商高得多:你既然决定去万达广场,总是要买点东西或者看个电影、唱个卡拉OK吧?哪一样不得花银子?

于是,他们得到的下一个结论就是万达不做B2C,要做O2O。具体怎么做呢?他们想了个办法,就是建立大会员体系。所谓“大会员”,就是这个会员资格在全国所有的万达广场、万达酒店、万达文化园区内都是通用的,而且要在万达广场的所有门店中都是通用的。消费者在“万达系”的任何一个商家消费都能够获得积分,积分也是通用的,能够直接拿到万达广场的3万多商家中消费。目前,万达已经在全国20多家万达广场中做“大会员”试点,鼓励消费者办理会员卡,并计划将其推广到全国所有的万达广场。万达计划在两年之内,将万达广场的消费者转化成一亿名万达会员。有了这一亿名会员,万达才算是真正掌握住了自己的客户。

如果“大会员”进展顺利的话,万达同时就可以玩“大数据了”。例如,能够根据会员每次来万达广场的消费情况,给这些会员进行归类,打上标签。此后,万达也就能够经营会员了,例如帮助商家筛选消费者,做个性化营销。例如,我是万达广场中一家卖礼品的商家,情人节想搞个促销活动,就可以通过万达电商的后台,挑选出一批25-30岁的单身男女,然后根据他们所处的地理位置,有针对性地向他们推送促销信息。

有了“大会员”和“大数据”,万达其实已经能够帮商家干很多事情了。例如,过去商家搞促销,必须雇人到万达广场门口发纸质优惠券,发出1万份能回收800份就不错了,还得贴上近1万元的制作成本。有了“大会员”和“大数据”之后,商家就可以直接从后台的数据库中挑选出适合的消费者,通过短信或微信等各种渠道做精准营销,成本也要低很多。

有了“大会员”和“大数据”,万达还能够将商圈拓展到万达广场之外。例如,在万达广场周围的小商户中设置能刷万达会员卡的POS机,给这些小商户带来新的流量,也给会员提供了更多的便利。

有了“大会员”和“大数据”,万达就可以跟第三方商家打交道了。例如,万达可以跟银行信用卡中心、航空公司、连锁加油站等商家合作,他们每年发的卡里面都有大量的积分花不出去,就可以跟万达会员卡谈个兑换比例,让他们的会员到万达广场来消费。

这就是万达的O2O,能够做到扬长避短。老冀认为,同样是两个“O”,万达看重的还是线下的那个“O”。至于线上的那个“O”,无论是自家的万汇网、万汇App,还是第三方的微信、团购,只是给线下的“O”提供导流的作用。大家觉得,万达的O2O是不是比苏宁硬桥硬马地直接做B2C更可行一些?

不过,想法可行,并不代表一定就能做起来。作为消费者,我已经有了优衣库、沃尔玛的卡,为什么还要办万达会员卡?作为商家,如果客户都去刷万达会员卡了,我获取新客户的收益还抵不上支出,我为什么要接纳万达会员卡?另外,如果我手中已经有了很大的客户数据,我为什么要与万达共享?这些利益上的问题,都需要万达设计出一套很好的商业模式来解决。

 

要做成“大会员”和“大数据”不是那么容易的,既需要成熟的会员营销方法论,还需要可用的CRM软件,更需要懂得会员营销的运营团队,万达需要的是一整套解决方案。为了尽快找到这套解决方案,万达一方面广招贤才,另一方面则找了4家“外脑”IBM、西门子利多富、甲骨文、雅座来招标,让外部专家来说说到底应该怎么搞。出于意料的是,3家“高大上”的外企却没能赢得万达的欢心,反倒是雅座在线这家本土的小公司赢得了万达的信任。在这里,老冀不禁要为万达捏一把汗:虽然雅座在连锁餐饮企业的会员营销方面做得很不错,也有一套成熟的解决方案,但是毕竟从来没有做过这么复杂的商业广场项目,万达也真敢赌!

总之,万达的O2O看起来可行,但是要真正见到成效,恐怕也不是一年两年的事情,作为老板的王健林恐怕还需要多点耐心。

更新时间:03/20/2014
贴吧图片
0

 

谷歌CEO佩奇谈互联网隐私:不要因噎废食

  新浪科技讯 北京时间3月20日早间消息,谷歌(1199.25, -12.01, -0.99%)CEO拉里·佩奇(Larry Page)周三在温哥华举行的TED大会上表示,虽然隐私问题值得重视,但不应该因噎废食,不假思索地一味保护隐私。

  佩奇起初迟迟不肯公布自己的喉咙究竟出了什么问题,但当他对外公布实情后,立刻收到了数以千计与他有类似情况的人的回复,这也让他意识到开放的价值。他甚至认为,如果人们能将自己的病例匿名分享到网上,今年大约会有10万人的生命得到拯救。

  他在TED大会上说:“我很担心互联网隐私,我们对待此事的态度与对待病例类似,我们正在不加区分地把婴儿和洗澡水一起倒掉。我们并没有考虑,将正确的信息,通过正确的方式,与正确的人分享之后,所得到的巨大利益。”

  诚然,隐私问题十分重要。“世界变了,如果你拿着手机,它就知道你在那里。”佩奇说,“关于你的信息已经大幅增多。人们询问不同的问题的确在情理之中。而我认为,我们应该做的就是为他们提供选择,向他们展示哪些数据会被收集,并告知他们搜索历史和定位数据。我们对Chrome的隐身浏览模式感到振奋,并且在通过更多方式实现这种服务。但我们只是为人们提供了更多选择,让他们知道事情的进展。”

  佩奇一直在强调人工智能和上网的好处,他同时也在批评美国政府的监视行为。“棱镜门”泄密者爱德华·斯诺登(Edward Snowden)周二也通过远程视频参与了TED,谷歌联合创始人谢尔盖·布林(Sergey Brin)还借助视频会议与他合影。

  “没有安全就没有隐私。”佩奇说,“如果我们必须要预防用户受到政府的监视,那就没有民主可言。我们应该知道,这些监视活动的目的、方法和原因,但政府却将这一切保密。我认为我们应该就此展开辩论,否则便无法建立有序的民主制度。

更新时间:03/20/2014
贴吧图片
8

各位,我希望本届的 Android 程序设计竞赛能够从 trustie 平台上进行。
能否提供一个类似于 App Store 的功能?具体需求:

1. 参赛者能够上传自己的 android 程序,包括 apk 文件、程序logo、截图、版本更新。
2. 所有人员均可下载程序,并进行打分(五分制或者百分制),评价留言。
3. 每个 id 只有在下载过程序后才能评价,可以实名货值匿名。
4. 界面参考 App Store、iTunes 或者 Android 软件市场。

最后回复:张鹏飞
03/18/2014
更新时间:03/18/2014
贴吧图片
1
再强调一下,帖子内容应该可以为空
最后回复:王春
03/13/2014
更新时间:03/13/2014
贴吧图片
1
  1. 综述
  2. 解决方法
    1. 服务代理模式
    2. 跨子域名的调用
    3. 跨源资源共享
    4. 使用JSONP协议
    5. 跨文档消息Cross-documentMessaging

 

综述

出于防范跨站脚本攻击的同源安全策略,浏览器禁止客户端脚本(如Javascript)对不同域名的服务进行跨域调用。

同源策略(Same Origin)中的源有着严格的定义,参见RFC6454,第4章节。一般而言,Origin由{protocol, host, port}三部分组成。

下面是同源检查的一些实例:

 

可能有点意外的是,一般我们会认为不同的子域名应该被当做同域名,是安全的调用,但实际上浏览器同源策略甚至禁止了不同子域名和端口的服务之间的调用。

 

解决方法

有时候上述限制过于严格,为了在两个不同Origin的网页(服务)之间进行通讯,我们可以采用如下的一些技术方法:

1、服务代理模式

即在web服务器上封装第三方服务,然后给自己同源的web页面调用。

 

2、跨子域名的调用

如果想从www.example.com调用api.example.com的html/xml数据服务,那么可以通过使用iframe,并在document和iframe中均设置相同的document.domain属性,那么document和iframe所对应的页面直接就可以通信而不会有任何安全冲突(security violation),注意必须设置相同的一级域名(document.domain="example.com"),不要设置子域名。代码示例如下:

t.html

 

[html] view plaincopyprint?

  1. <html>  
  2.   <head>  
  3.   <script type="text/javascript">  
  4.     document.domain = "example.com";  
  5.     function update_me(result) {  
  6.       document.getElementById('update-me').innerHTML = "Result: " + result;  
  7.     }  
  8.     function load() {  
  9.         var c = document.createElement('iframe');  
  10.         c.style.display = "none";  
  11.         c.src = "http://api.example.com/cross-subdomains-ajax/t-frame.html#" + document.domain;  
  12.         document.body.appendChild(c);  
  13.     }  
  14.   </script>  
  15.   </head>  
  16.   <body onload="load();">  
  17.     <div id="update-me"></div>  
  18.   </body>  
  19. </html>  
<html>
  <head>
  <script type="text/javascript">
    document.domain = "example.com";
    function update_me(result) {
      document.getElementById('update-me').innerHTML = "Result: " + result;
    }
    function load() {
        var c = document.createElement('iframe');
        c.style.display = "none";
        c.src = "http://api.example.com/cross-subdomains-ajax/t-frame.html#" + document.domain;
        document.body.appendChild(c);
    }
  </script>
  </head>
  <body onload="load();">
    <div id="update-me"></div>
  </body>
</html>


t-frame.html

 

 

[html] view plaincopyprint?

  1. <html>  
  2.   <head>  
  3.   <script type="text/javascript">  
  4.     function spoof(status, headers, result) {  
  5.       var old_domain = document.domain;  
  6.       document.domain = example.com;  
  7.       window.parent.update_me("Ok, got it from the frame !");  
  8.       try {  
  9.         document.domain = old_domain;  
  10.       } catch (e) { }  
  11.     }  
  12.     spoof();  
  13.   </script>  
  14.   </head>  
  15. </html>  
<html>
  <head>
  <script type="text/javascript">
    function spoof(status, headers, result) {
      var old_domain = document.domain;
      document.domain = example.com;
      window.parent.update_me("Ok, got it from the frame !");
      try {
        document.domain = old_domain;
      } catch (e) { }
    }
    spoof();
  </script>
  </head>
</html>

 

3、跨源资源共享

 

这是已经标准化的技术方法,参见W3规范文档Cross Origin Resouce Sharing:http://www.w3.org/TR/cors/

通过在服务端设置Access-Control-Allow-Origin响应头(一般回填$_SERVER['HTTP_ORIGIN']),

header('Access-Control-Allow-Origin: '.$_SERVER['HTTP_ORIGIN']);

来告诉浏览器该服务允许来自特定源的访问或者允许所有人访问。

尽管该规范支持使用origin list的形式,但实际浏览器实现只支持了单个origin、*、null,如果要配置多个访问源,可以在代码中处理如下(PHP):

 

[php] view plaincopyprint?

  1. $allowed_origins   = array(  
  2.                             "http://www.example.com"   ,  
  3.                             "http://app.example.com"  ,  
  4.                             "http://cms.example.com"  ,  
  5.                           );  
  6. if (in_array($_SERVER['HTTP_ORIGIN'], $allowed_origins)){    
  7.     @header("Access-Control-Allow-Origin: " . $_SERVER['HTTP_ORIGIN']);  
  8. }  
$allowed_origins   = array(
                            "http://www.example.com"   ,
                            "http://app.example.com"  ,
                            "http://cms.example.com"  ,
                          );
if (in_array($_SERVER['HTTP_ORIGIN'], $allowed_origins)){  
    @header("Access-Control-Allow-Origin: " . $_SERVER['HTTP_ORIGIN']);
}


或者在httpd配置或.htaccess文件(如果使用的是Apache服务器)中添加如下语句:

 

 

[plain] view plaincopyprint?

  1. SetEnvIf Origin "^(.*\.example\.com)$" ORIGIN_SUB_DOMAIN=$1  
  2. Header set Access-Control-Allow-Origin "%{ORIGIN_SUB_DOMAIN}e" env=ORIGIN_SUB_DOMAIN  
SetEnvIf Origin "^(.*\.example\.com)$" ORIGIN_SUB_DOMAIN=$1
Header set Access-Control-Allow-Origin "%{ORIGIN_SUB_DOMAIN}e" env=ORIGIN_SUB_DOMAIN


如用的是nginx,配置类似如下:

 

 

[plain] view plaincopyprint?

  1. location / {  
  2.     # this will echo back the origin header  
  3.     if ($http_origin ~ "example.com$") {  
  4.         add_header "Access-Control-Allow-Origin" $http_origin;  
  5.     }  
  6. }  
location / {
    # this will echo back the origin header
    if ($http_origin ~ "example.com$") {
        add_header "Access-Control-Allow-Origin" $http_origin;
    }
}

 

4、使用JSONP协议

出于同源策略,HTML禁止在两个页面之间进行通讯,但<script>元素是个例外,JSONP利用这个开放特性来实现跨域调用,

在客户端调用提供JSONP支持的URL Service,获取JSONP格式数据,然后在callback函数中处理返回的json协议数据:

 

[html] view plaincopyprint?

  1. <script type="text/javascript" src="http://api.example.com/getdata?jsonp=callback"></script>  
<script type="text/javascript" src="http://api.example.com/getdata?jsonp=callback"></script>

 

如使用jQuery的ajax调用方式,示范代码如下:

 

[javascript] view plaincopyprint?

  1. $.ajax({  
  2. dataType: 'jsonp',  
  3. data: 'id=10',  
  4. jsonp: 'jsonp_callback',  
  5. url: 'http://api.example.com/getdata',  
  6. success: function () {  
  7. // do stuff   
  8. },  
  9. });  
$.ajax({
dataType: 'jsonp',
data: 'id=10',
jsonp: 'jsonp_callback',
url: 'http://api.example.com/getdata',
success: function () {
// do stuff
},
});

 

5、跨文档消息(Cross-document Messaging)

这个是HTML5引入的一个在跨域页面之间通讯的方法,参见W3规范 http://dev.w3.org/html5/postmsg/

postMessage API应用范围主要有2个,1是文档和内嵌frame之间的消息通信,2是文档和自身通过脚本打开的windows之间的消息通信

最后回复:谭显波
03/12/2014
更新时间:03/12/2014
贴吧图片
0

Redmine 2.5.0 发布,此版本包括了许多改进和新特性,现已提供下载。此版本主要改进了自定义字段格式:

 

  • 支持文本格式

  • 支持 HTTP 链接

  • 提供给用户基于角色和版本状态的细粒度的选择

  • 完全重写了自定义字段格式的 API ;如果用户需要运行一些相关的插件(比如,添加非标准的字段格式),用户需要在升级之前更新

此版本同时还引入了对  Markdown 格式的支持,这是个非常流行的文本格式语法编辑。更多内容请查看Changelog

 

Redmine 2.4.4 版本是个维护版本,主要包括了一些缺陷修复和升级了 Rails 到 3.2.17 版本。

Redmine 是一个开源的、基于Web的项目管理和缺陷跟踪工具。它用日历和甘特图辅助项目及进度可视化显示。同时它又支持多项目管理。Redmine是一个自由开放 源码软件解决方案,它提供集成的项目管理功能,问题跟踪,并为多个版本控制选项的支持。

虽说像IBM Rational Team Concert的商业项目调查工具已经很强大了,但想坚持一个自由和开放源码的解决方案,可能会发现Redmine是一个有用的Scrum和敏捷的选择。 由于Redmine的设计受到Rrac的较大影响,所以它们的软件包有很多相似的特征。

Redmine建立在Ruby on Rails的框架之上,支持跨平台和多种数据库。。

更新时间:03/11/2014
贴吧图像
我在问吧
回答
发帖

问吧

新建贴吧
问题和建议
还能输入50个字符 Submit

加入QQ群

关注微信APP


×