SegmentFault 技术周刊 Vol.22 - 进击的 Google I/O 2017

Google I/O 2017聚焦人工智能技术,推出了Google Assistant、Google Lens等服务,展示了Android O的新特性,并宣布正式支持Kotlin作为Android开发语言。

SegmentFault 技术周刊 Vol.22 ##Google I/O Google I/O 是由 Google 举行的网络开发者年会,讨论的焦点是用 Google 和开放网络技术开发网络应用。Google I/O 早已成为全球计算机爱好者关注的焦点,北京时间 5 月 18 日凌晨 1 点,Google I/O 2017 在美国加州山景城的海岸线圆形剧场拉开帷幕。

今年 Google I/O 的几大看点:

  • Google Assistant
  • Google Lens
  • Google Home
  • Google Photos
  • Cloud TPU
  • Android O
  • VR/AR

###Google Assistant 在去年的 Google I/O 大会上,Google 的 AI 用 Google Assistant 的方式初步落地,Google Assitant 是一个不仅能回答问题还能围绕一个话题陪你聊天的语音智能助手,而今年的 Google I/O 上,Google Assistant 的能力得到进一步的加强,专注于听觉和视觉识别的大方向,是语音、文字、图像三大沟通形式的整合。

谷歌 CEO Sundar Pichai 表示,Google Assistant 与搜索并列,是谷歌机器学习技术最重要的产品/服务载体。

###Google Lens Google Lens 是谷歌全新计算机视觉服务的名称,可以理解为一个强大的视觉搜索引擎,所见即所得的理解整个视觉世界,并为你提供服务建议。它智能识别取景器中的图像内容(如用户智能手机中的照片),并作出相应的操作回馈。其使用场景包括:识别旅游地标;提取照片中的文字信息、手机号码;与谷歌翻译整合的实时翻译等。

###Google Home Google Home 是一个集成了 Google Assistant 语音识别助手的智能音箱,除了播放音乐、搜索、建议安排待办事项等常见功能,Google Home 还能成为智能家居产品的中枢,根据用户需求,完成调节温度、开启灯光等任务。 而这次 Google Home 获得了一个最重要的功能:“Hands Free Calling”,用户可以直接通过 Google Home 拨打电话,而它并不像其它音箱一样与手机连接后成为手机的扬声器,而是真正可以脱离手机直接拨打电话。

###Google Photos 谷歌宣布了 Google Photos 基于机器学习技术的全面升级,很可能是其诞生以来的最大升级。Google Photos 将利用机器学习技术自动为照片添加标签、进行分组、自动对照片效果进行调整(比如自动翻转)。 Google Photos 还可以做很多的图像处理工作,比如把模糊的照片变得更清楚。此外它还将整合 Google Lens 的图像识别能力,提供一系列新特性,比如识别照片中的电话号码。

###Cloud TPU TPU 的全称为:TensorFlow Processing Unit(TensorFlow 处理单元),是 Google 专为自家的深度学习框架 TensorFlow 而推出的处理器,安装在数据中心的服务器中。 在去年的 I/O 大会上,谷歌宣布了其第一代 TPU。围绕着人工智能,Google 也重新改造计算中心,并发布了一个新的芯片 TPU 2.0 或者说 Cloud TPU。

###Android O 和上一代系统 Android N 相比,Android O 更加面面俱到了。原先的多窗口模式将被分成上下两个界面,在 Android O 上,画中画功能比多窗口模式更实用。

###VR/AR 在 VR 和 AR 领域,Google 更多的是与其他厂商合作,例如 HTC vive,联想等,让用户在没有 PC 的情况下,更好的获得 VR 和 AR 的体验。

Google I/O 全记录,多希望我们能用上这些“未来科技”

我们再一次领教了 Google 如何把晦涩难懂的人工智能技术,包装成了聪明智能的 Google Lens,Google Assistant 等服务,让我们知道,这是人工智能,而不是“人工智障”。

##人工智能

本次 Google I/O 2017 的 Keynote 是:Mobile first to AI first。我们炒过智能穿戴,炒过 VR 和 AR,还炒过工智能和机器学习,之所以没火就是因为它们离我们太远。

Google I/O 2017 | 使 AI 触手可及

Google 欣喜的看到,人工智能终于结出了每个人均可品尝享用的硕果。倘若 Google 能让人工智能技术越来越便捷地为民众所用——无论是在工具层面,还是应用方式层面——那么,所有人都会更快地从人工智能技术中获益。

毫无疑问,AI 成为了今年 Google I/O 大会的绝对主角,大会上“人工智能”、“深度学习”也频频出现。

人工智能是否会超越人类智慧?- 施米德休教授采访

孩子们甚至某些小动物仍比我们最好的自我学习的机器人更聪明。但我认为,在未来的某一点,我们也许能够建立一个基于NN增量式学习的人工智能程序(NNAI),可以学习到小动物的聪明程度,学习如何计划和推理,把各种各样的问题分解成能快速解决(或已经解决)的子问题。

人工智能时代的降临

人工智能接管的世界即将来临,让我们拥抱它吧。

##深度学习 基础深度学习概念备忘录

深度学习可能对于很多初学者是一头雾水,在高速发展的同时有很多新的概念名词被抛出,而本文则是对一些常见名词的备忘介绍。

[译]深度学习的基础框架

深度学习属于经验学科,随着现在研究的进展所用到的基础框架也在不断地完善。幸运地是,开源系统让任何人都有搭建一个深度学习架构的可能。

基于 Deep Learning 的视频识别方法概览

人工智能在视频上的应用主要一个课题是视频理解,努力解决“语义鸿沟”的问题。传统的手工特征有一大堆,目前效果较好的是 iDT (Improved Dense Trajectories) ,深度学习对图像内容的表达能力十分不错,在视频的内容表达上也有相应的方法。

机器学习、深度学习与自然语言处理领域推荐的书籍列表

包括数学基础、机器学习、深度学习、自然语言处理、泛数据科学五个方面。

##Google 正式支持 Kotlin 今年的 Google I/O 上, 专门邀请了Jake Wharton (Square员工,Butterknife 作者,知名 Kotlin 推动者)来分享 Kotlin 心得,Google 终于正式支持了JetBrains的编程语言 Kotlin, 将其作为 Android 的官方开发语言。对于开发者而言,这绝对是一个激动人心的好消息。

欢呼声热烈 谷歌宣布 Kotlin 成 Android 开发一级语言

谷歌宣布,将 Kotlin 语言作为安卓开发的一级编程语言。Kotlin 由 JetBrains 公司开发,与 Java 100% 互通,并具备诸多 Java 尚不支持的新特性。JetBrains 在 2010 年首次推出 Kotlin 编程语言,并在次年将之开源。下一版的 Android Studio(3.0)也将提供支持。

快速学习一门语言最简单粗暴的方法当然是亲自动手实践一个项目,现在就来试一试:

谷歌宣布 Kotlin 成安卓开发一级语言,我们如何来学习它

笔者根据多年编程经验,编程语言都应该在思想上互通的,如果,没有想到这一点。学习之路苦不堪言。今天分享下,当拿到一个新语言时,如何来学习。

使用 Kotlin 优雅的开发 Android 应用

我们该如何在 Android 中应用这门新的语言呢?今天的这篇文章带你学习使用 Kotlin 开发 Android 应用,并对比我们传统语言 Java,让你真真切切的感受到他的美和优雅。

##进一步研究 Kotlin 而对于一些小伙伴,早早就已经开始实践出真知了:

研究学习Kotlin的一些方法

虽然 Kotlin 使用简单快捷,然而由于自己的深入研究的习惯导致每接触到 Kotlin 的新功能,就马不停蹄的研究它的本质,这里总结一下关于如何研究 Kotlin 的一些方法来快速研究掌握 Kotlin。

用 Kotlin 写 Android ,难道只有环境搭建这么简单?

作为有经验的开发人员,大家都知道 Android 现在基本上都用 gradle 构建,gradle 构建过程中只要加入 Kotlin 代码编译的相关配置,那么 Kotlin 的代码运用到 Android 的问题就解决了。

最后,附上学习任何一门语言必备的秘笈:

Kotlin 中文文档

(本期完) <br>


# SegmentFault 技术周刊 #

「技术周刊」是社区特别推出的技术内容系列,一周一主题。周刊筛选的每篇内容,是作者的独到见解,踩坑总结和经验分享。

每周四更新,欢迎「关注」或者「订阅」。大家也可以在评论处留言自己感兴趣的主题,推荐主题相关的优秀文章。

转载于:https://my.oschina.net/SegmentFault/blog/1083073

<think> 我们正在处理一个XSS验证失败的问题,具体错误是"old url warning",验证类为`weaver.security.rules.SecurityRuleOldUrlCheck`,请求路径为`/api/log/workflow/processLog/getRequestFlowLog`,来源IP为113.108.155.50,referer为`http://8.134.70.228:8889/wui/engine.html`。 根据引用[1]和[2]的信息,我们得知: - 引用[1]展示了一个XSS攻击的日志记录,其中尝试注入脚本。 - 引用[2]展示了一段用于验证URL是否属于安全域(www.segmentfault.com)的代码,如果安全则加载脚本,否则返回无效URL。 因此,我们的问题可能与安全规则检查有关,特别是检查URL是否为旧版本的URL(可能因为安全原因被标记)。 **可能的原因分析:** 1. **请求的referer URL(即`http://8.134.70.228:8889/wui/engine.html`)被安全规则标记为旧URL或不安全。** 2. 安全规则`SecurityRuleOldUrlCheck`可能检查referer的域名或URL是否在允许的白名单中,或者是否使用了最新版本的URL(避免使用旧版URL可能存在的漏洞)。 3. 请求中的referer使用的是IP地址(8.134.70.228)而非域名,同时端口为8889,这可能触发安全规则(因为通常生产环境使用域名且端口为标准端口)。 **解决思路:** 1. **检查安全规则配置**:确认`SecurityRuleOldUrlCheck`规则的配置,查看它具体检查什么条件。通常这类规则会检查referer的合法性和时效性。 2. **将IP地址加入白名单**:如果该IP是合法的内部地址,可以考虑将IP或该referer URL加入白名单。 3. **使用域名代替IP访问**:如果可能,使用配置的域名访问系统,避免使用IP地址,因为安全规则可能要求使用域名。 4. **更新referer URL版本**:如果是由于使用了旧版URL(如包含`engine.html`的旧路径)导致,尝试更新到新版URL。 **具体步骤:** **步骤1:检查安全规则配置** - 查找`SecurityRuleOldUrlCheck`类的配置,通常在系统的安全配置文件中。可能位于`weaver.security.xml`或类似的安全规则配置文件中。 - 查看该规则的白名单(allowlist)设置,确认是否允许使用IP地址作为referer。 **步骤2:将referer加入白名单** - 如果确认该referer(`http://8.134.70.228:8889`)是合法的,可以将该URL添加到安全规则的白名单中。 - 例如,在配置文件中添加类似下面的配置: ```xml <rule class="weaver.security.rules.SecurityRuleOldUrlCheck"> <allowlist> <url>http://8.134.70.228:8889</url> <!-- 其他允许的URL --> </allowlist> </rule> ``` - 修改配置后需要重启应用服务。 **步骤3:使用域名访问** - 建议通过配置的域名(如`http://yourdomain.com:8889`)来访问系统,而不是直接使用IP地址。这样安全规则可能不会将其视为旧URL。 **步骤4:检查referer URL的版本** - 如果系统已经升级,旧版URL(如`engine.html`)可能已被弃用。请更新前端页面,使用新版本的URL。 **步骤5:检查请求的来源IP(113.108.155.50)** - 确认该IP是否是合法的客户端IP。如果不是,可能是恶意请求,可以忽略或通过防火墙阻止该IP。 - 如果是合法请求,确保该IP也在安全规则允许的范围内。 **附加建议:** - 检查系统日志,确认是否有其他类似的错误,以便了解是否是普遍问题。 - 更新系统到最新版本,确保已知的安全问题已被修复。 如果以上步骤仍无法解决问题,请提供更多关于安全规则配置的信息,以便进一步分析。 §§相关问题§§ 1. 如何配置Weaver系统的安全规则白名单? 2. 在Weaver系统中如何查看和修改安全规则? 3. 如何升级Weaver系统以避免旧URL的问题? 4. 如何通过日志追踪XSS攻击的来源? </think> ### XSS验证失败(old url warning)问题分析和解决方案 根据您提供的信息,问题涉及`SecurityRuleOldUrlCheck`类在验证路径`/api/log/workflow/processLog/getRequestFlowLog`时触发"old url warning"警告,来源IP为113.108.155.50,referer为`http://8.134.70.228:8889/wui/engine.html`。以下是系统分析和解决方案: --- ### **问题根本原因** 1. **URL白名单验证失败** 引用[2]中的代码显示安全验证依赖正则表达式检测URL合法性: ```javascript let domainRe = /^https?:\/\/www\.segmentfault\.com/ ``` 当前referer(`http://8.134.70.228:8889`)未匹配白名单规则,触发`SecurityRuleOldUrlCheck`的旧URL警告机制[^2]。 2. **IP直接访问风险** 来源IP(113.108.155.50)直接通过IP地址而非域名访问API,安全规则通常将此类请求视为潜在风险[^1]。 3. **URL版本控制机制** `old url warning`表明系统检测到API调用使用了过时的URL路径或参数格式,需更新调用方式[^2]。 --- ### **解决方案** #### 1. 更新Referer白名单配置 ```xml <!-- 在安全规则配置文件(如security-rules.xml)中添加 --> <rule class="weaver.security.rules.SecurityRuleOldUrlCheck"> <allowed-referers> http://8.134.70.228:8889 <!-- 添加当前IP到白名单 --> https://yourdomain.com <!-- 补充正式域名 --> </allowed-referers> </rule> ``` > **验证方法**:重启服务后检查日志,确认警告是否消失。 #### 2. 前端调用规范化 修改发起请求的前端代码,确保: - 使用域名而非IP访问API - 更新过时的URL路径(如替换`/wui/engine.html`为新版本路径) ```javascript // 正确示例(使用域名和规范路径) fetch("https://yourdomain.com/api/v2/log/workflow/processLog") ``` #### 3. 安全规则调试 在测试环境启用调试模式,定位具体验证失败点: ```java // SecurityRuleOldUrlCheck 类中添加日志 logger.debug("验证失败: Referer=" + request.getReferer() + " | Path=" + path); ``` #### 4. IP访问限制(可选) 若113.108.155.50非合法IP,可在防火墙/Nginx添加拦截: ```nginx location /api/log { deny 113.108.155.50; # 拦截特定IP allow 192.168.0.0/16; # 允许内网 } ``` --- ### **预防措施** 1. **迁移到HTTPS** 将referer的`http://`升级为`https://`,避免安全策略拦截[^2]。 2. **版本兼容处理** 在API网关添加路径重写规则,兼容旧版URL调用: ```nginx rewrite ^/api/log/workflow/processLog/getRequestFlowLog$ /api/v2/log/workflow last; ``` 3. **安全扫描** 使用XSS扫描工具(如OWASP ZAP)检测`engine.html`页面漏洞,排除注入风险[^1]。 > **重要提示**:修改后需在测试环境验证,避免影响生产系统。若问题持续,检查`SecurityRuleOldUrlCheck`类的自定义逻辑是否包含特殊校验规则。 ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符  | 博主筛选后可见
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值