Indicate whether to send a cookie in a cross-site request by specifying its SameSite attribute

最近在浏览器(Chrome 85.0.4183.121)调试网页的时候,出现如下警告信息:

继续阅读Indicate whether to send a cookie in a cross-site request by specifying its SameSite attribute

WordPress隐藏前台登录用户名

最近在查看Limit Login Attempts日志的时候,发现大量的登陆尝试,关键是登陆使用的用户名是正确的。感到很奇怪,用户名是如何泄漏的呢?

网上搜寻了一下,发现原来用户名是被WordPress主动泄漏出来的。

WordPress鼠标点击前台用户名,浏览器就会跳转到 https://www.mobibrw.com/author/username 这个链接,这样一来就直接暴露了登陆用户名,哪怕你已经在前台使用了昵称。这是个很大的安全隐患!

后台登陆用户名也可以这样查看到:https://www.mobibrw.com/?author=1,多用户的可以把 1 变为 2、3、4、5 等,就可以在地址栏查看到各个用户名。

为了避免暴露登陆用户名,我们需要配置禁止用户名显示。我们需要在当前使用的主题的functions.php中增加如下函数

参考链接


com.android.tools.r8.ApiLevelException: Invoke-customs are only supported starting with Android O

原因是某些第三方库使用了Java 1.8API,导致整个项目必须使用Java 1.8

解决方法就是增加如下编译命令

完整的例子如下:

参考链接


Hudson/Jenkins -- 消除svn警告: "clock of the subversion server appears to be out of sync"

Hudson/Jenkins中配置svnURL时,有时会出现如下警告信息:

基本选择每次重新checkout最新的版本,也会出现该警告信息。

并且经常无法获取到最新的代码,要等几分钟之后才能拉取到最新的代码。

这个在编译的时候有时候会有这个警告,主要是svn等服务器的时钟和本机的时钟有偏差,比如svn的时钟比较快,jenkins的时钟慢,当你提交svn的时候,紧接着进行jenkins构建,这个时候jenkinssvn update由于时钟原因就更新不到刚才的数据,但过了几分钟之后再进行更新的时候,超过两台机器的时间差,在次进行jenkins构建,就可以update到数据。

继续阅读Hudson/Jenkins -- 消除svn警告: "clock of the subversion server appears to be out of sync"

Android 6.0/10.0扫描不到Ble设备需开启位置权限

蓝牙设备扫描需要定位权限的原因在于蓝牙定位的存在,蓝牙定位属于精确定位,因此需要开启精确定位权限,而精确定位跟GPS又是直接相关的,因此才会导致GPS权限需要获取。

项目中需要用到android Ble蓝牙4.0开发技术,于是开启了蓝牙填坑之旅,说实话,蓝牙开发坑真多,跳出一个又进入下一个,每次遇到 问题,就觉得不可能解决了,还好在自己的摸索中,都一一的化解了,以此来记录安卓蓝牙开发的心得。

     接手的蓝牙开发项目,原来的同事已经写好,不用再去写,开始也就大概看了看android蓝牙开发相关资料,对比项目中的蓝牙开发代码,发现发现搜索、连接蓝牙有一样的处理也有不一样的处理,想着项目不一样,代码处理肯定不一样,于是就没去深究,毕竟项目运行起来使用正常,然而,没过几天,客户提出蓝牙搜索太慢,然后就去调试,先看代码是搜索蓝牙8秒钟才显示搜索到的蓝牙设备列表,查看日志,其实不到8秒就搜索到外围设备,只是搜索8秒后停止扫描才显示蓝牙设备,那就把显示成3、4秒呗。
        正这样想,同事拿来一部荣耀8,装的APP怎么就是搜不到蓝牙设备,然后调试其他手机,都能搜索到,于是就纳闷了,荣耀8怎么就是搜索不到蓝牙设备呢,其他手机都能,再看一遍代码,也没有专门针对荣耀8处理的地方,再想,荣耀8是系统7.0的手机,是不是跟权限没开有关呢,对比其他华为手机,申请的蓝牙权限也都开着,荣耀8就是搜索不到,是不是荣耀8手机有问题,同事告知下载一个第三方蓝牙调试工具查查看,令人疑惑的是荣耀8用第三方蓝牙调试工具立刻就能扫描显示出来,试了几次都是立刻扫描出来,当时心想,我靠,什么鬼,这么迅速就能把蓝牙设备扫描显示出来,领导也说,别人的调试工具都能做这么快,你也得做这么快,想着目前的代码都是几秒后才能搜索到,目前的荣耀8还搜索不出来,客户那边还一个劲儿的给老板吐槽太慢,于是压力剧增,真正开始了蓝牙开发不归之旅。
     但是再考虑索慢时,领导说,得把荣耀8搜索不到的问题先解决,因为荣耀8是项目实施人员给客户安装硬件调试数据要用的,那就先把搜索慢暂时放一放,想着一边搜索慢没还没着落,荣耀8手机就是搜索不到,想想就头大,查找荣耀8为什么搜索不到蓝牙设备的资料,也没发现有效的办法,这时,用荣耀手机的人说,另一个公司的项目app(简称B吧,荣耀8搜索不到蓝牙设备的项目简称A吧)就能正常搜索到蓝牙设备,一打开调试还真是每次都能搜索到,看了一下两个项目的代码:

      两个项目中的蓝牙适配器的获取,去发现,动态注册广播、广播接收蓝牙搜索结果、蓝牙连接都一样,至于手机是否支持ble4.0,蓝牙是否开启的逻辑,连接上对数据的处理、断开mBluetoothGatt.disconnect(),关闭mBluetoothGatt.close() 的逻辑网上有很多,我这里就不在详说;
       经过2个项目对比,发现就蓝牙搜索多久停止不一样,荣耀8能搜索到蓝牙设备的时间项目代码设置是10秒,而搜索不到的项目是设置8秒,带着半信半疑把项目A的蓝牙搜索时间由8秒改成10秒,运行,奇迹还真是出现了,荣耀8可以正常搜索到蓝牙设备了,反复测了好多次都能正常搜索到蓝牙设备,我是不信邪的人,还改成8秒试试,果然还是搜索不到。
     于是和领导说,你看荣耀8必须10秒才能搜索 到蓝牙设备,搜索到的蓝牙设备列表不晚点展示不行啊,领导自然 是不同意,拿出第三方蓝牙提哦啊是工具说,那第三方就能很快搜索到,你想想其他法吧,想着有的手机快,有的手机慢,提出意见,能不能搜索到一个设备就展示到列表,不必等10秒后再展示,这样体验好些,反正领导说不行,既然领导说不行,那就回去研究吧。
    查了很多蓝牙搜索慢怎么办?看了半天,当然这期间调试过各种其他方法,都没用,功夫不负有心人,其中一个博客说:
btAdapt.startDiscovery();搜索返回的结果慢, 现在都用这个 btAdapt.startLeScan(getmLeScanCallback); 其他也没多说什么,喜出望外,这不是正是我要的吗,于是改蓝牙搜索,上代码: