在升级 discourse 后，很多内容没有办法正确显示。 通过 F12 查看浏览器后，发现有提示 https 和 http 的混合内容。 下面是混合内容常在浏览器中看到的提示。 不管是不是对系统进行重启或者刷新缓存都没有办法解决。 强制使用 https 其实 Discourse 如果安装的时候使用了 https ，那么你可用修改配置强制所有内容都使用 https。 在默认的情况下，Discourse 都会使用 Let’s Encrypt 来对你的网站进行加密。 配置的路径在 ：admin/site_settings/category/security 下面 你也可以直接搜索 force_https 在完成上面的配置后，你可以重启 docker 来刷新配置。 https://www.ossez.com/t/discourse-https/550
如果你安装使用的是 CentOS 的话，你可能没有办法直接安装 htop。 你会得到下面的信息： [[email protected] discourse]# htop -bash: htop: command not found 解决办法 你可用将 RHEL 添加到你的仓库中。 运行下面的命令： yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm 上面的命令将会添加 RHEL 到仓库中，在过程中你需要输入 Y 来同意校验。 在完成上面的操作后，再执行 yum install htop 来执行安装。 在完整完成后，可用使用 htop 命令来查看系统的运行情况。 如果你可以看到上面的界面，则表明 htop 已经安装成功。
如果你安装使用的是 CentOS 的话，你可能没有办法直接安装 htop。 你会得到下面的信息： [[email protected] discourse]# htop -bash: htop: command not found 解决办法 你可以将 RHEL 添加到你的仓库中。 运行下面的命令： yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm 上面的命令将会添加 RHEL 到仓库中，在过程中你需要输入 Y 来同意校验。 在完成上面的操作后，再执行 yum install htop 来执行安装。 在完整完成后，可使用 htop 命令来查看系统的运行情况。 如果你可以看到上面的界面，则表明 htop 已经安装成功。
在更新或者安装 docker 容器的时候，提示下面的错误： Problem: package docker-ce-3:19.03.13-3.el7.x86_64 requires containerd.io >= 1.2.2-3 上面的问题如何解决。 解决 根据提示的内容，上面已经说得比较明确了。 就是需要使用 containerd.io 的版本要升级下。 你可以访问 docker 官方的链接有关 CentOS 的安装部分： Install Docker Engine on CentOS 首先你需要设置仓库： sudo yum install -y yum-utils sudo yum-config-manager \ --add-repo \ https://download.docker.com/linux/centos/docker-ce.repo 然后执行命令 sudo yum install docker-ce docker-ce-cli containerd.io 就可以解决上面的问题了。 https://www.ossez.com/t/centos-8-docker-containerd-io-1-2-2-3/548
让我们讨论下 JSON Web Tokens (JWT) 针对 Simple Web Tokens (SWT) 和 Security Assertion Markup Language Tokens (SAML) 而言有什么优势吧。 相对 XML 来说，JSON 格式更加简洁，对 JSON 格式进行编码后的数据量更小，这就使得 JWT 相对 SAML 来说显得更加小巧，这使得 JWT 更加容易能够在 HTTP 和 HTML 环境之间传递数据。 在安全性上面，SWT 只能使用通过 HMAC 算法的对称方式签名。JWT 和 SAML 都可以使用基于 X.509 认证的公钥/私钥 密钥对的方式进行加密和解密。相比针对 JSON 格式的签名，针对XML 的数字签名更加容易导入安全漏洞。 在 JSON 格式的处理上，当前几乎所有的语言都能够支持和进行解析，这是因为 JSON 格式的数据更加容易映射到数据对象中。XML 则没有针对文本到对象的映射支持。这就导致了相对 SAML 来说，JWT 的处理更加容易。 在使用方面，JWT 已经被大量的在互联网上面取得了应用，针对多平台的使用上，JSON 格式在客户端上面更加容易被使用，尤其是针对移动平台。 针对 JSON 和 SAML 数据格式的内容对比，请参考下面的图片： 从上面的图片的对比上，我们可以看到基于 JSON 格式的内容更少，表达性更好。 如果你希望了解更多有关 JSON Web Tokens 的使用，并且打算开始在你的系统中应用这种格式，请参考由 Auth0 官方提供的介绍和文档，访问链接是：http://auth0.com/learn/json-web-tokens。 https://www.ossez.com/t/json-web-tokens/537
很多人可能都不知道自己的 2345 ，360 怎么就被装上去了。 软件厂商耍流氓又不是一天两天了。 来源不明的软件，可能会被植入病毒，流氓软件，木马等等。 官版这部分问题就没有，也不会触发防病毒软件误报。
我们喜欢做快餐式的软件。 其实中国软件还是不错的，比应用层的话，我都怀疑这么小的屏幕怎么能塞下那么多东西。 我们差的是基础软件。这些东西做起来旷日持久，还需要不停的投入和市场培养。 一个抄袭成风，只希望一夜暴富的市场和环境，怎么可能做出那么多好东西？ 做软件也需要创造力的，可惜我们只会服从，公司也喜欢听话的。 没有创造力，一切看起来就没有那么美好了。 如果有一天，所有平台不再无缘无故 404 了，那就有希望了。 现在还是先解决 404 的问题吧。
不需要。直接修改环境变量就可以了。 根据使用的操作系统不同，不同的操作系统可能有所不同。 Windows 的话 PATH 看一下 指向的 JDK 是哪个路径。 如果你要CMD 查看的话，你需要关闭 CMD 窗口，然后重新打开。
时间长了，就好像很多东西用久了，容易年久失修。 如果拿我们现在的地铁，机场和美国去比，真的美国的好多机场地铁，可以说实在不好看，容易感觉到美国基建很差。 再等几十年吧，等我们修好的东西用几十年再看是不是还一样。说不定我们早拆了，好处是还能看新的。
在用户权限校验的过程中，一个用户如果使用授权信息成功登录后，一个 JSON Web Token 将会返回给用户端。 因为返回的令牌包含有授权信息，应用程序应小心保存这些授权信息，以避免不必要的安全问题。你的应用程序在不需要授权信息的时候，应用程序不应该保留授权成功后返回的令牌。 应用程序也不应该将这些敏感信息保存在浏览器中，因为这样会更加容易导致信息泄漏，请参考链接：https://cheatsheetseries.owasp.org/cheatsheets/HTML5_Security_Cheat_Sheet.html#local-storage 中的内容。 在任何时候，如果用户希望访问一个受保护的资源或者路由的时候，用户应该在访问请求中包含 JWT 令牌。通常这个令牌是存储在 HTTP 请求的头部信息，一般会使用 Authorization 字段，使用 Bearer 模式。 Http 头部发送给后台所包含的内容看起来如下所示： Authorization: Bearer <token> 在某些情况下，可以使用无状态的授权机制。服务器上受保护的路由将会检查随着访问提交的 JWT 令牌。如果令牌是有效的，用户将会被允许访问特定的资源。 如果 JWT 令牌中包含有必要的信息，服务器的服务端将不需要再次对数据库进行查询以加快访问速度。当然，不是所有的时候都可以这样进行处理。 当令牌随着头部中的 Authorization 信息一同发送，那么我们不需要使用 cookies，因此跨域访问（Cross-Origin Resource Sharing (CORS)）也不应该成为一个问题。 下面的示例图展示了JWT 是如何被获得的，同时也展示了 JWT 是如何被使用来访问服务器 API 的。 1. 应用程序或者客户端，通过对授权服务器的访问来获得授权。这个可能有不同的授权模式。例如，通常我们可以使用 OpenID Connect 提供的标准的授权地址来进行授权，请参考链接：http://openid.net/connect/。通常来说一个标准的授权地址为 /oauth/authorize，并且使用下面类似的标准授权流程，请参考链接：http://openid.net/specs/openid-connect-core-1_0.html#CodeFlowAuth 中的内容。 2. 当授权完成后，授权服务器将会返回访问令牌（access token）给应用。 3. 应用使用获得的令牌来访问收到保护的资源（例如 API）等。 需要注意的是，通过使用了签名的令牌，尽管用户可能没有办法对使用的令牌进行修改，但是令牌中包含的所有信息将会暴露给用户或者其他的应用。因此，你不应该在你的令牌中存储密钥或者任何的敏感信息。 https://www.ossez.com/t/json-web-tokens/532