macOS Monterey (12.0.1)解决App Store无法下载APP的问题

最近,公司的一台电脑升级到 macOS Monterey (12.0.1),之后从进行软件更新,以及 XCode 的下载安装。由于网速的限制,临时把 XCode 的下载进行了暂停操作,之后忘记恢复就进行了重启。

结果第二天在App的安装界面上就看不到被暂停的任务了。然后在 App Store 中尝试继续进行下载,发现无法进行下载任务,下载按钮点击之后,状态一闪而过,又回到待下载状态。

更换账号/重启应用/重启系统之后,无法解决问题。

应该是 App Store 内部状态混乱了,导致无法进行下载任务,需要对 App Store 进行重置操作。

网上搜索很久,才找到解决方案,执行如下命令:

之后重启系统,重新点击下载应用,即可解决问题。

参考链接


OS X EI Capitan(10.11.6)报错'os/availability.h' file not found

解决方案:

参考链接


macOS Big Sur(11.4)安装指定版本Node

参考链接


NSURLProtocol -- DNS劫持和Web资源本地化

什么是DNS劫持

DNS劫持就是通过劫持了DNS服务器,通过某些手段取得某域名的解析记录控制权,进而修改此域名的解析结果,导致对该域名的访问由原IP地址转入到修改后的指定IP,其结果就是对特定的网址不能访问或访问的是假网址,从而实现窃取资料或者破坏原有正常服务的目的。
 常见的DNS劫持现象网络运营商向网页中注入了Javascript代码,甚至直接将我们的网页请求转发到他们自己的广告页面或者通过自己的DNS服务器将用户请求的域名指向到非法地址

如何解决DNS被劫持

全站使用HTTPS协议,或者采用HttpDNS,通过HTTP向自建的DNS服务器或者安全的DNS服务器发送域名解析请求,然后根据解析结果设置客户端的Host指向,从而绕过网络运营商的DNS解析服务。

本文的解决方案

客户端对WebView的html请求进行DNS解析。优先使用阿里、腾讯、114等公共安全的DNS服务器解析客户端的所有指定域名的http请求。相对来讲我们自己的服务域名变化较少,对此我们做了一个白名单,把凡是访问包含我们公司域名的请求都必须通过白名单的解析和DNS验证。从而杜绝被劫持的情况出现,这时候NSURLProtocol就派上用场了。

NSURLProtocol

这是一个抽象类,所以在oc中只能通过继承来重写父类的方法。

然后在AppDelegate的 application:didFinishLaunchingWithOptions: 方法或者程序首次请求网络数据之前去注册这个NSURLProtocol的子类

注册了自定义的urlProtocol子类后,之后每一个http请求都会先经过该类过滤并且通过+canInitWithRequest:这个方法返回一个布尔值告诉系统该请求是否需要处理,返回Yes才能进行后续处理。

+canonicalRequestForRequest:这个父类的抽象方法子类必须实现。

以下是官方对这个方法的解释。当我们想对某个请求添加请求头或者返回新的请求时,可以在这个方法里自定义然后返回,一般情况下直接返回参数里的NSURLRequest实例即可。

It is up to each concrete protocol implementation to define what “canonical” means. A protocol should guarantee that the same input request always yields the same canonical form.

+requestIsCacheEquivalent:toRquest:这个方法能够判断当拦截URL相同时是否使用缓存数据,以下例子是直接返回父类实现。

-startLoading-stopLoading两个方法分别告诉NSURLProtocol实现开始和取消请求的处理。

由于我们在-startLoading中新建了一个NSURLConnection实例,因此要实现NSURLConnectionDelegate的委托方法。

至此,通过NSURLProtocol和QNDnsManager(七牛DNS解析开源库)可以解决DNS劫持问题。但是NSURLProtocol还有更多的用途,以下是本文第二个内容:webView上web请求的资源本地化。

Web资源本地化

这里只举一个简单的示例,同样是在上述NSURLProtocol的子类的-startLoading方法里

继续阅读NSURLProtocol -- DNS劫持和Web资源本地化

OS X EI Capitan curl: (22) The requested URL returned error: 403 [[[!!! BREAKING CHANGE !!!]]] Support for clients that do not support Server Name Indication is temporarily disabled and will be permanently deprecated soon.

最近在OS X EI Capitan系统上执行升级工作的时候,发生错误,内容如下:

排查了很久,发现是以前为了修复 解决macOS系统curl报告https证书不正确(curl: (60) SSL certificate problem: Invalid certificate chain)问题而配置了curl忽略安全配置信息导致的,如下:

移除这个配置项目即可解决问题。

参考链接


禁止macOS系统产生.DS_Store文件的方法

Mac经常会产生 .DS_Store 的隐藏文件,虽然在 Mac 上看不到,但是有时用了人家的 U 盘或把 U 盘拿到 Windows 系统上用,就会看到。

.DS_StoreMac OS 保存文件夹的自定义属性的隐藏文件,如文件的图标位置或背景色,相当于Windowsdesktop.ini

  • 禁止 .DS_Store 生成:
    打开 “终端” ,复制黏贴下面的命令,回车执行,重启Mac即可生效。

  • 恢复 .DS_Store 生成:

参考链接


解决GitHub的raw.githubusercontent.com无法连接问题

https://site.ip138.com/raw.Githubusercontent.com/

输入raw.githubusercontent.com

查询IP地址

修改hosts Ubuntu,CentOS及macOS直接在终端输入

添加以下内容保存即可 (IP地址查询后相应修改,可以ping不同IP的延时 选择最佳IP地址

# GitHub Start
52.74.223.119 github.com
192.30.253.119 gist.github.com
54.169.195.247 api.github.com
185.199.111.153 assets-cdn.github.com
199.232.96.133 raw.githubusercontent.com
#151.101.76.133 raw.githubusercontent.com
151.101.108.133 user-images.githubusercontent.com
151.101.76.133 gist.githubusercontent.com
151.101.76.133 cloud.githubusercontent.com
151.101.76.133 camo.githubusercontent.com
151.101.76.133 avatars0.githubusercontent.com
151.101.76.133 avatars1.githubusercontent.com
151.101.76.133 avatars2.githubusercontent.com
151.101.76.133 avatars3.githubusercontent.com
151.101.76.133 avatars4.githubusercontent.com
151.101.76.133 avatars5.githubusercontent.com
151.101.76.133 avatars6.githubusercontent.com
151.101.76.133 avatars7.githubusercontent.com
151.101.76.133 avatars8.githubusercontent.com
# GitHub End

参考链接


Error: Your CLT does not support macOS 11.0.

最近系统升级到macOS Big Sur(11.0.1)之后,系统报告如下错误:

解决方案如下:

参考链接


AX88179 USB网卡无法在macOS Big Sur(11.0.1)系统上正常使用

Background
Last year, we wrote that older macOS drivers, known as System Extensions (KEXTs), would begin to be deprecated as of the macOS 10.15 Catalina release. This week, as macOS 11 Big Sur is released, KEXTs have officially been deprecated and are no longer functional.

Instead, Apple is now enforcing the requirement for devices that require third-party drivers to operate as DriverKit Extensions (DEXTs). This change affects many products across the consumer electronics industry, including Docking Stations, USB peripherals, Security/Anti-Virus software, and Networking adapters.

Luckily, most platform vendors and integrated circuit (IC) manufacturers have been prepared for this change and began working on their DEXT implementation after Apple released pertinent documentation at their WWDC (World Wide Developer Conference) in June 2019.

Unfortunately, some vendors could not begin their full transition from KEXT to DEXT until this year. Not all pertinent DriverKit documentation was released at the 2019 event as expected, but, instead, was released at WWDC 2020 in June. Specifically, for Plugable and many other brands, this applies to ASIX-based USB Ethernet Adapters like our USB3-E1000, USBC-E1000, USB2-E1000, and USB2-E100, which we wrote about here for the release of macOS 10.15 Catalina:
https://plugable.com/2019/10/04/usb-ethernet-adapter-not-working-after-macos-catalina-10-15-update-we-can-help/

Current Status for ASIX-based Ethernet Adapters [Novemeber 13, 2020]
We began removing macOS support from our most popular wired network adapters (USB3-E1000 and USBC-E1000) in October 2019. We saw the continued potential for a poor or broken user experience with ASIX-based adapters on macOS and could not in good conscience market the adapters as fully compatible in the long-term as long as ASIX was unwilling to commit to continued development and support of their ICs on macOS.

We have continued to push ASIX for a DEXT beta driver to validate and test internally in the past year. Unfortunately, ASIX has been unable to deliver this solution as requested in anticipation of this significant macOS milestone. We expect a Beta driver from ASIX by the end of November for AX88179 products like the USB3-E1000 and USBC-E1000. Once the driver is validated, we will update this blog post and product driver pages with links to download the driver.

If a wired Ethernet connection is critical to your workflow, Plugable recommends not updating to macOS 11 Big Sur from macOS 10.15 Catalina.

At this time, Plugable is unable to provide a DEXT driver for the following products:
USB3-E1000 IC: AX88179
USBC-E1000 IC: AX88179
USB2-E1000 IC: AX88178 (ASIX has discontinued the IC in this product, and they have not committed to a compatible driver for macOS 11 Big Sur)
The USB2-E100 IC: AX88772 ASIX-based product continues to function, utilizing the in-box drivers in macOS.

We understand this news can be frustrating for our customers and is a situation we have been working to avoid for over one year. We will update this blog post as new information is available to us.

While we cannot promise a functional DEXT driver at any point in the future, if you would like to be notified of that news should it occur, please sign-up on the form below, and we will email everyone as soon as it is available.

继续阅读AX88179 USB网卡无法在macOS Big Sur(11.0.1)系统上正常使用

macOS 10.15.7运行JNLP文件

系统升级到macOS 10.15.7之后,发现JNLP文件无法打开了,默认的Java被切换到OpenJDK了。

但是根据官方说明,从Java 1.8开始,OpenJDK已经默认不携带Java Web Start功能了,这些功能被限定为Oracle JRE专有的功能。因此默认的javaws已经无法找到了。

Java Web Start (JWS) was deprecated in Java 9, and starting with Java 11, Oracle removed JWS from their JDK distributions. This means that clients that have the latest version of Java installed can no longer use JWS-based applications. And since public support of Java 8 has ended in Q2/2019, companies no longer get any updates and security fixes for Java Web Start.

解决方法有两个,一个是使用 OpenWebStart 来打开JNLP文件,可惜的是,目前功能不够完善,很多应用无法正常运行,比如HP Gen8集成远程控制台系统的Java Web Start

另一个是使用 Orocle JRE 来打开JNLP文件,目前这个功能是比较好用的,就是需要注册账号才能下载。

参考连接