CAS单点登录（第7版）27.开发人员

如有疑问，请看视频：CAS单点登录（第7版）

开发人员
1. Javadocs文档

group org.apereo.cas has published 42 artifact(s) with total 8210 version(s)

org.apereo.cas

org apereo.cas 小组已出版 42 件作品，共 8210 个版本

Artifact	Num# versions published	Latest version
cas-management	9	5.3.6
cas-server	86	6.1.0-RC1
cas-server-core	232	7.2.0-RC3
cas-server-core-api	235	7.2.0-RC5
cas-server-core-api-authentication	232	7.2.0-RC3
cas-server-core-api-configuration-model	184	7.2.0-RC3
cas-server-core-api-validation	232	7.2.0-RC3
cas-server-core-authentication	232	7.2.0-RC3
cas-server-core-authentication-api	187	7.2.0-RC4
cas-server-core-authentication-attributes	198	7.2.0-RC3
cas-server-core-authentication-mfa	195	7.2.0-RC3
cas-server-core-authentication-mfa-api	160	7.2.0-RC3
cas-server-core-configuration	230	7.2.0-RC3
cas-server-core-rest	185	7.2.0-RC4
cas-server-core-services	234	7.2.0-RC4
cas-server-core-services-api	198	7.2.0-RC3
cas-server-core-services-authentication	198	7.2.0-RC3
cas-server-core-util-api	185	7.2.0-RC3
cas-server-core-validation	232	7.2.0-RC3
cas-server-core-web	232	7.2.0-RC3
cas-server-core-web-api	185	7.2.0-RC3
cas-server-core-webflow-api	185	7.2.0-RC3
cas-server-core-webflow-mfa-api	160	7.2.0-RC3
cas-server-support-jdbc	232	7.2.0-RC3
cas-server-support-oauth	235	7.2.0-RC5
cas-server-support-oauth-core	232	7.2.0-RC3
cas-server-support-oauth-core-api	146	7.2.0-RC3
cas-server-support-oauth-services	211	7.2.0-RC3
cas-server-support-oauth-uma-core	159	7.2.0-RC3
cas-server-support-oidc	232	7.2.0-RC3
cas-server-support-oidc-core-api	146	7.2.0-RC3
cas-server-support-otp-mfa-core	159	7.2.0-RC3
cas-server-support-redis-ticket-registry	213	7.2.0-RC3
cas-server-support-rest-core	146	7.2.0-RC3
cas-server-support-saml-idp-web	184	7.2.0-RC3
cas-server-support-shell	231	7.2.0-RC3
cas-server-support-simple-mfa	162	7.2.0-RC3
cas-server-support-validation	231	7.2.0-RC3
cas-server-support-x509	232	7.2.0-RC3
cas-server-support-x509-core	210	7.2.0-RC3
cas-server-webapp	232	7.2.0-RC3
cas-server-webapp-tomcat	211	7.2.0-RC3

1. 代码约定
  1. 代码约定

在 Apache 和 Eclipse 等成熟项目的引领下，CAS 中的所有代码都将遵守 Java 代码约定以及下面列出的 CAS 特定约定。Javadoc 应存在于所有公开导出的类成员中，并遵循标准准则。

以下文档介绍了特定于 CAS 项目的一组编码约定：

1. 1. 工具

当前的代码库利用 Checkstyle 引擎来尽可能地执行约定。使用 SpotBugs 还会执行一定数量的检查。

在适当的情况下，代码库利用 Project Lombok 自动生成代码结构，例如 getter 和 setter 等。

1. 1. 一致性

在引入新组件、字段和文件时，请尽量与现有命名模式保持一致。例如，如果 CAS 组件被命名为 SimpleCipherExecutor，则其自然替代项可能被设计为 FancyCipherExecutor。

1. 1. 文档

通常，所有公共 API 都应在合理的范围内得到充分记录，同样，作为该字段 Javadocs 的一部分，所有 CAS 配置设置和属性都应通过示例、默认值等进行全面解释。

1. 1. 括弧

所有括号都应以紧凑的形式出现，即使对于单行语句也是必需的。

public class FooClass {

public void barMethod() {

if (...) {

// single line statement

}

1. 1. 不必要的 else 子句

public class FooClass {

public String barMethod() {

if (...) {

return "foo";

}

return bar;

}

1. 1. Getter/Setter 方法

为字段生成 Getter/Setter 方法通常是使用 Project Lombok 的 @Getter 和 @Setter 注释完成的。

1. 1. 构造函数

创建构造函数通常使用 Project Lombok 的 @NoArgsConstructor、@AllArgsConstructor 或 @RequiredArgsConstructor 注释来完成。

1. 1. 缺口

代码缩进应设置为使用 4 个空格。制表符绝不应用于缩进。

1. 1. 静态杆件

静态成员变量将始终为大写，其中每个单词都用下划线分隔：

1	private static final String SOME_OBJECT = "TheObject";

1. 1. Logging

我们使用 SLF4J 进行日志记录。除非另有说明，否则 LOGGER 对象将使用 Project Lombok 的 @Slf4j 注释生成。

参数化日志消息是首选：

1 2	final Object entry = new SomeObject();logger.debug("The entry is {}.", entry);

这是检查特定日志记录级别并通过 String 对象连接参数的首选方法。

1. 1. 使用 this 限定实例变量

尝试使用 this 来限定所有实例变量，但 Logging 实例除外。

1. 1. var var使用

建议局部变量使用 Project Lombok 的 val。在需要可变性的情况下，建议使用 var。

1. 1. 命名测试用例

如果我们为 Foo.java 中定义的代码编写 JUnit 测试用例，我们会将其命名为 FooTests.java。我们不允许任何非测试用例的代码名称以 “Tests” 结尾。所有测试用例都必须使用注解 (@Test) 而不是扩展 junit.framework.TestCase。此外，通常不鼓励使用 junit.framework 类。

1. 1. 注射

对于必需的依赖项，必须使用构造函数注入，而 setter 可用于可选依赖项。

1. 1. toString（）、equals（）、hashCode（）方法

查看 Project Lombok 的 @ToString 和 @EqualsAndHashCode 注释。

1. 发布流程
  1. CAS 发布流程

本页记录了发布工程师在剪切 CAS 服务器版本时应采取的步骤。

1. 1. Sonatype 设置

您需要注册一个 Sonatype 帐户，并且必须通过创建 JIRA 请求获得授权才能将版本发布到 org.apereo 包。一旦你这样做了，你可能会被要求让一位当前的项目成员为你担保。

1. 1. GPG 设置

在将发布构件上传到中央存储库之前，您需要生成自己的 PGP 签名来对发布构件进行签名。为了创建 OpenPGP 签名，您需要生成一个密钥对。您需要向 build 提供您的关键信息，这意味着三件事：

公钥 ID（keyId 的最后 8 个符号。你可以使用 gpg -K 来获取它）。

包含您的私钥的密钥环文件的绝对路径。从 gpg 2.1 开始，您需要使用以下命令导出密钥：

1	gpg --keyring secring.gpg --export-secret-keys > ~/.gnupg/secring.gpg

用于保护私钥的密码。

上述设置需要放入 ~/.gradle/gradle.properties 文件中：

signing.keyId=7A24P9QBsigning.password=P@$$w0rdsigning.secretKeyRingFile=/Users/example/.gnupg/secring.gpg

有关如何使用 Gradle 签名插件对工件进行签名的其他说明，请参阅此处

1. 1. 环境设置

加载您的 SSH 密钥，并确保 GitHub 中也引用了此 SSH 密钥。

如有必要，调整 $GRADLE_OPTS 以初始化 JVM 堆大小。

加载 ~/.gradle/gradle.properties 文件，以以下内容为例：

1 2	org.gradle.daemon=falseorg.gradle.parallel=false

查看 CAS 项目：git clone git@github.com:apereo/cas.git cas-server

确保您通过 java -version 安装了最新版本的 JDK 21。

1. 1. 准备发布

应用以下步骤来准备发布环境。根据是否应该创建新的发布分支，需要考虑一些变化。

1. 1. 1. 创建分支

1 2	# Replace $BRANCH with CAS version (i.e. 6.5.x) git checkout -b $BRANCH

记得

您应该仅对主要或次要版本（即 4.2.x、5.0.x）执行此操作。如果要发布的版本已经存在远程跟踪分支，则应 git checkout 该分支，跳过此步骤并转到下一部分进行构建和发布。

1. 1. 1. GitHub 操作

记得

您应该只对主要或次要版本在创建新分支时执行此操作。

将 GitHub Actions 工作流更改为触发并仅构建新创建的发布分支：

analysis.yml

validation.yml

publish.yml

publish-docs.yml

functional-tests.yml

tests.yml

on:

workflow_dispatch:

push:

branches:

- $NEW_BRANCH

- '!**.**.**'

- '!heroku-*'

pull_request:

types: [ labeled ]

branches: [ $NEW_BRANCH, pr-* ]

然后禁用以下工作流：

build.yml

dependencies.yml

native-tests.yml

可以通过以下方式在 YAML 配置中禁用这些：

on:

workflow_dispatch:

push:

branches-ignore:

- '**'

不要忘记提交所有更改并将更改推送到上游，创建一个新的远程分支来跟踪发布。

1. 1. 执行发布

在项目的 gradle.properties 中，将项目版本更改为发布版本，并删除 -SNAPSHOT（即 6.0.0-RC1）。

使用以下命令生成并发布项目：

1	./ci/release.sh

该脚本将提示输入相应的 Sonatype 用户名和密码（或用户令牌）。您还可以通过预先将凭证指定为环境变量，以非交互模式运行脚本：

1 2	export REPOSITORY_USER="..."export REPOSITORY_PWD="..."

请勿使用您的实际密码，而是创建用户令牌。这是它所属用户的一种凭证形式，与原始密码完全不同且分开。可以轻松创建和删除用户令牌，这在安全策略需要更新凭证或凭证意外丢失或其他情况下非常有用。

1. 1. 完成发布

该脚本将自动为已发布版本创建标签，提交更改并将标签推送到上游仓库。（即 v5.0.0-RC1）。

您还应该切换回主开发分支（即 master）并按照以下步骤操作：

在项目的 gradle.properties 中，将项目版本更改为下一个开发版本（即 5.0.0-SNAPSHOT

将您的更改推送到上游存储库。

1. 1. 家政

记得

更新版本描述时，请尽量保持一致并遵循与以前版本相同的布局。

在 GitHub 上发布项目的 RC 版本时，请记住将发布标签标记为预发布。

1. 1. 更新 CAS 初始化

确保更新 CAS Initializr 以允许基于新发布的版本生成项目。

1. 1. 更新文档

记得

您应该只对主要或次要版本在创建新分支时执行此操作。

在此处配置 docs 以将current可用版本指向最新可用版本。

修改配置文件以从构建中排除相关分支和目录。

配置 docs 以将新版本包含在可用版本列表中。

如有必要，请更新项目的 README.md 页以列出新版本。

更新构建过程以包含有关如何构建新版本的任何必要信息。

更新 Algolia 以获取新的文档版本，以便为搜索请求的新空间编制索引。

更新发行说明概述并删除所有以前的条目。

1. 1. 更新维护策略

记得

您应该只对主要或次要版本在创建新分支时执行此操作。

更新维护策略以记录发布计划和 EOL 时间表。

1. 构建过程
  1. CAS 构建过程

本页记录了 CAS 开发人员/贡献者在本地构建 CAS 服务器时应采取的步骤。

使用警告！

如果您即将部署和配置 CAS，那么您来错地方了！要在本地部署 CAS，请使用特定 CAS 版本的项目文档中描述的 WAR Overlay 方法。仅当您希望为项目的开发做出贡献时，才需要从源代码克隆、下载和构建 CAS 代码库。

1. 1. 源检出

以下 shell 命令可用于从存储库中获取源代码：

1	git clone --recursive git@github.com:apereo/cas.git cas-server

或者更快的克隆：

1 2	git clone --recursive --depth=1 --single-branch --branch=master git@github.com:apereo/cas.git cas-server# git fetch --unshallow

要成功克隆，您需要在 GitHub 上为您的帐户设置 SSH 密钥。如果无法执行此操作，您可以通过 https://github.com/apereo/cas.git 在 https 下克隆 CAS 存储库。

您可能还需要更新链接到 CAS 存储库的子模块。较新版本的 Git 会自动执行此操作，但旧版本会要求你明确告诉 git 下载子模块的内容：

1	git submodule update --init --recursive

1. 1. 建立

以下 shell 命令可用于构建源代码：

1 2	cd cas-server git checkout master

完成后，您可以通过以下命令构建代码库：

1	./gradlew build --parallel -x test -x javadoc -x check --build-cache --configure-on-demand

Gradle 包装器和口香糖

您可能希望使用 Gum，而不是直接使用 Gradle Wrapper，它能够自动检测项目结构中任意位置的 Gradle Wrapper。

构建支持以下命令行布尔标志，并且可以通过 -D 以系统属性的形式传递：

旗	描述
enableRemoteDebugging	允许通过预定义端口（即 5000）进行远程调试。
remoteDebuggingSuspend	设置为 true 可暂停 JVM 远程调试，直到调试器连接到正在运行的会话。
verbose	控制测试的日志记录级别，并输出有关通过/失败/跳过测试的其他数据。
skipCheckstyle	跳过运行 Checkstyle 检查。
skipVersionConflict	如果发现依赖项冲突，请使用最新版本，而不是使构建失败。
skipNestedConfigMetadataGen	跳过为嵌套属性和泛型集合生成配置元数据。
skipSonarqube	忽略向 Sonarqube 报告结果。
skipErrorProneCompiler	跳过运行error-prone的静态分析编译器。
skipBootifulArtifact	不要应用 Spring Boot 插件来引导应用程序工件。
skipBootifulLaunchScript	在引导最终的 Web 应用程序构件时，不要包含启动脚本。
skipAot	在构建 Graal VM 原生镜像时跳过运行 AOT 进程。
aotSpringActiveProfiles	构建 Graal VM 本机映像时要使用的 Spring 活动配置文件列表。
ignoreJavadocFailures	忽略 javadoc 失败，让构建继续。
ignoreFindbugsFailures	忽略 Findbugs 失败，让构建继续。
ignoreTestFailures	忽略测试失败，让构建继续。
casModules	Build 属性;不带 cas-server-[support/api/core] 的逗号分隔模块列表
buildScript	生成项目时要包含的生成片段。通常由集成测试使用，并在集成测试期间使用。
generateGitProperties	在最终的 Web 应用程序工件中包含 Git 信息。
generateTimestamps	在最终的 Web 应用程序构件中包含构建时间戳。

您可以使用 -x <task> 完全跳过/忽略构建中的某个阶段。（即 -x test， -x check）。

如果你不需要让 Gradle 为你解析 / 更新依赖项和新的模块版本，你可以在构建时利用 --offline 标志，这往往会使构建进行得更快。

使用 Gradle 守护进程也是一个很大的帮助。默认情况下，它应该是启用的。

通过 --build-cache 启用 Gradle 的构建缓存也可以显著缩短构建时间。

1. 1. 任务

可以使用命令 ./gradlew tasks 找到可用的构建任务。

1. 1. IDE 设置

可以使用任何支持 Gradle 的现代 IDE 进行 CAS 开发。

1. 1. 1. IntelliJ IDEA

以下 Gradle 的 IDEA 设置也可能很有用：

注意

您应该始终使用最新版本的 Intellij IDEA。

此外，您可能需要自定义 VM 设置，以确保开发环境可以加载代码库并为其编制索引：

-Xms2g

-Xmx8g

-XX:+UseStringDeduplication

-XX:+ParallelRefProcEnabled

使 IntelliJ IDEA 能够很好地处理项目的关键点是为其提供大量内存（通过指定 -Xmx8g VM 选项或在 Help -> Change Memory Settings）中）。

如果您仍在使用 JDK 8 运行 IntelliJ，则可能需要以下选项：

-server

-Xms1g

-Xmx8g

-Xss16m

-XX:NewRatio=3

-XX:ReservedCodeCacheSize=512m

-XX:+UseCompressedOops

-XX:SoftRefLRUPolicyMSPerMB=50

-XX:+CMSClassUnloadingEnabled

-XX:+CMSParallelRemarkEnabled

-XX:CMSInitiatingOccupancyFraction=65

-XX:+CMSScavengeBeforeRemark

-XX:+UseCMSInitiatingOccupancyOnly

-XX:MaxTenuringThreshold=1

-XX:SurvivorRatio=8

-XX:+UseCodeCacheFlushing

-XX:+AggressiveOpts

-XX:-TraceClassUnloading

-XX:+AlwaysPreTouch

-XX:+TieredCompilation

-Djava.net.preferIPv4Stack=true

-Dsun.io.useCanonCaches=false

-Djsse.enableSNIExtension=true

-ea

插件

以下插件在开发过程中可能很有用：

Checkstyle
FindBugs
Lombok

安装 Lombok 插件后，您还需要确保 Annotation Processing 已打开。您可能需要重新启动 IDEA 才能使更改完全生效。

请注意，可以将 CAS 提供的 Checkstyle 规则导入到 idea 中，以自动执行许多与包导入和布局特别相关的格式规则。导入后，规则应类似于以下屏幕截图：

运行 CAS

通过创建大致与以下屏幕截图匹配的运行配置，可以直接从 IDEA 运行 CAS Web 应用程序：

此设置允许开发人员通过嵌入式 servlet 容器运行 CAS Web 应用程序。

1. 1. 测试模块

请参阅此页面以了解有关测试流程和指南的更多信息。

1. 1. 嵌入式容器

CAS 项目附带了许多内置模块，这些模块预先配置了嵌入式 servlet 容器，例如 Apache Tomcat、Jetty 等，用于服务器 Web 应用程序、管理 Web 应用程序等。这些模块位于 CAS 项目的 webapp 文件夹中。

1. 1. 1. 配置 SSL

thekeystore文件必须包含为 CAS 服务器域颁发的 SSL 私有密钥/公钥。您需要使用 JDK 的 keytool 命令来创建密钥库和证书。

以下命令可以作为示例：

1 2	keytool -genkey -alias cas -keyalg RSA -validity 999 -keystore thekeystore -ext san=dns:casserver.houwang.edu

请注意， validity 参数允许您指定证书的有效期（以天数为单位）。时间段越长，您就越不需要重新创建它。要重新创建它，您需要删除旧的，然后再次按照这些说明进行操作。您可能还需要提供 Subject Alternative Name 字段，这可以通过 keytool 通过 -ext san=dns:casserver.houwang.edu 完成。

响应将如下所示：

Enter keystore password: changeit

Re-enter new password: changeit

What is your first and last name?

[Unknown]: casserver.houwang.edu (i.e. casserver.houwang.edu)

What is the name of your organizational unit?

[Unknown]: houwang

What is the name of your organization?

[Unknown]: houwang

What is the name of your City or Locality?

[Unknown]: xiaan

What is the name of your State or Province?

[Unknown]: shaanxi

What is the two-letter country code for this unit?

[Unknown]: CN

Is CN=casserver.houwang.edu, OU=houwang, O=houwang, L=xiaan, ST=shaanxi, C=CN correct?

[no]: y

在您的 /etc/hosts 文件（在 Windows 上：C:\Windows\System32\Drivers\etc\hosts）中，您可能还需要添加以下条目：

1	127.0.0.1 casserver.houwang.edu

从密钥库中导出的证书还需要导入到 Java 平台的全局密钥库中：

# Export the certificate into a file

keytool -export -file cas.crt -keystore thekeystore -alias cas

# Import the certificate into the global keystore

# sudo keytool -import -file cas.crt -alias cas -keystore $JAVA_HOME/lib/security/cacerts

keytool -import -file cas.crt -alias cas -keystore cacerts

…其中 JAVA_HOME 是安装 JDK 的位置（即 /Library/Java/JavaVirtualMachines/jdk[version].jdk/Contents/Home）。

在 Windows 上，应将管理权限授予控制台而不是 sudo，并且应将 $JAVA_HOME/lib/security/cacerts 更改为 "%JAVA_HOME%/lib/security/cacerts"

备注：keytool 错误: java.lang.Exception: 证书未导入, 别名 <cas> 已经存在

keytool -delete -alias cas -keystore cacerts -storepass changeit

1. 1. 1. 部署

执行以下命令：

cd webapp/cas-server-webapp-tomcat

../../gradlew build bootRun --parallel --offline --configure-on-demand --build-cache --stacktrace

响应将如下所示：

...

INFO [org.apereo.cas.web.CasWebApplication] - <Started CasWebApplication in 21.893 seconds (JVM running for 36.888)>

...

在D:\apache-tomcat-10.1.34\conf\server.xml文件中增加以下配置：

<Connector port="8443" protocol="org.apache.coyote.http11.Http11NioProtocol"

maxThreads="150" SSLEnabled="true"

maxParameterCount="1000"

<UpgradeProtocol className="org.apache.coyote.http2.Http2Protocol" />

<SSLHostConfig>

<Certificate certificateKeystoreFile="conf/thekeystore"

certificateKeystorePassword="changeit" type="RSA"

certificateKeystoreType="JKS"/>

</SSLHostConfig>

</Connector>

默认情况下，CAS 将在 https://casserver.houwang.edu:8443/cas

1. 1. 1. 远程调试

嵌入式容器实例已预先配置为侦听端口 5000 上的调试器请求，前提是您指定了 enableRemoteDebugging 参数。对于外部容器部署（如 Apache Tomcat），以下示例显示了需要在 bin/startup.sh|bat 文件中配置的内容：

export JPDA_ADDRESS=5000export JPDA_TRANSPORT=dt_socket

bin/catalina.sh jpda start

完成后，在 IDE 中创建一个连接到此端口的远程调试器配置，您将能够单步执行代码。

1. 1. 手动子模块测试

请参阅此页面以了解有关测试流程和指南的更多信息。

1. 1. 示例构建别名

以下是一些方便的构建别名示例，用于从项目快速运行本地 cas 服务器或从项目安装依赖项以在 cas-overlay 中使用。

# Adjust the cas alias to the location of cas project folderalias cas='cd ~/Workspace/cas'

# Run CAS with module selections# $> bc oidc,gauthfunction bc() {

clear

cas

cd webapp/cas-server-webapp-tomcat

casmodules="$1"

if [ ! -z "$casmodules" ] ; then

echo "Loading CAS Modules: ${casmodules}"

# Could also use: gm -b ./build.gradle

../../gradlew build bootRun \

--configure-on-demand --build-cache \

--parallel -x test -x javadoc -x check -DenableRemoteDebugging=true \

--stacktrace -DskipNestedConfigMetadataGen=true \

-DremoteDebuggingSuspend=false --no-configuration-cache \

-DcasModules=${casmodules}}

# Install JARs/WARs for use with a CAS overlay projectalias bci='clear; cas; \

./gradlew clean build publishToMavenLocal \

--configure-on-demand --no-configuration-cache \

--build-cache --parallel \

-x test -x javadoc -x check --stacktrace \

-DskipNestedConfigMetadataGen=true \

-DskipBootifulArtifact=true'

1. 测试流程
  1. 测试流程

本页记录了 CAS 开发人员/贡献者在开发过程中测试 CAS 服务器部署时应采取的步骤。有关一般构建过程的其他说明和指导，请参阅此页面。

贡献

以拉取请求形式提交到 CAS 代码库的补丁必须通过所有自动化单元或集成测试，和/或为提议的更改提供足够的单元或集成测试。在没有合适的测试用例的情况下，贡献很可能不会被接受到代码库中，最终可能会被关闭。

1. 1. 测试用例

项目中的以下类型的测试用例是 CAS 开发人员/贡献者需要审查的测试用例：

记得

如果您要描述一个问题，请尝试将一个测试用例放在一起，在一个相当隔离的环境中以自动化的方式具体演示该问题，尽可能没有手动说明和指导。描述性说明和语言来解释必须手动执行什么（即转到此处、单击那里、等待 3 秒等）才能重现问题或环境，这些不如问题的证据有效或可接受，并且可能需要大量时间和研究投资才能最终找到根本原因。为您自己和其他人节省时间和头痛，并将自动化、可重复、可验证的重现器组合在一起。

1. 1. 1. 单元测试

单元测试由通常可以单独测试的小工作或功能组成。它们被创建为 Java 测试类，单个测试场景通常使用 @Test 注释进行注释，然后由测试框架执行。

例如，src/main/java/Extractor.java 类型的组件的测试用例将位于 src/test/java/ExtractorTests.java 测试类中。

1. 1. 1. 集成测试

在某些情况下，单元测试还会针对数据库、外部系统或 API 运行一系列测试，以验证集成的功能和正确性。例如，MongoDbTicketRegistry 类型的组件将需要一个 MongoDb 运行实例以及特殊的标记和注释，以便在该外部实例启动并运行时运行测试。从结构上讲，此类测试与普通的 vanilla 单元测试几乎相同，并且可能只包含额外的装饰和注释，具体取决于测试系统。

1. 1. 1. 功能测试

功能测试是从最终用户的角度验证场景和行为组合的测试类别。此类测试通常由执行脚本和场景组成，并且可能涉及无头浏览器来运行场景、验证屏幕上的数据元素等。此类测试通常非常有效地重现与问题或可能缺陷相关的场景，并且对故障排除和问题诊断非常有帮助。

1. 1. 测试模块

要测试给定 CAS 模块提供的功能，请执行以下步骤：

对于 Apache Tomcat、undertow 或 Jetty Web 应用程序，请将模块引用添加到您打算运行的 Web 应用程序的 webapp-dependencies.gradle 构建脚本中：

1	implementation project(":support:cas-server-support-modulename")

或者，自动传递所需的模块：

1	bc ldap,x509

…其中 bc 是用于构建 CAS 的别名。

准备嵌入式容器，以运行和部署 Web 应用程序。

1. 1. 单元/集成测试

为了简化测试执行过程，您可以利用存储库根目录中的 testcas.sh 脚本，如下所示：

1 2	# chmod +x ./testcas.sh ./testcas.sh --category <category> [--test <test-class>] [--debug] [--with-coverage]

要了解有关该脚本的更多信息，请使用：

1	./testcas.sh --help

所有单元测试和集成测试都由持续集成系统执行。

1. 1. 代码覆盖率和指标

代码覆盖率指标由以下平台收集和报告：

系统	徽章
贡献
SonarCloud 云
CodeCov

质量指标由以下平台收集和报告：

系统	徽章
贡献
SonarCloud 质量门
SonarCloud 可维护性

1. 1. 浏览器和功能测试

自动浏览器测试是通过 Puppeteer 框架完成的。Puppeteer 是一个 Node 库，它提供了一个高级 API 来通过 DevTools 协议控制 Chrome 或 Chromium，并且默认无头运行。

功能测试首先生成一个普通的 CAS 覆盖作为基准，该基准能够使用预先生成的密钥库在 HTTPS 下运行。此覆盖提供了测试方案配置，该配置说明了在嵌入式 Apache Tomcat 容器中部署 CAS 时要使用的所需模块、属性等。运行后，Node 将针对给定的测试场景执行 Puppeteer 脚本，以验证特定功能，例如成功登录、生成票证等。

要查看所有 Puppeteer 测试场景的完整列表，您可以运行：

1	ls ./ci/tests/puppeteer/scenarios

所有功能和浏览器测试场景都由持续集成系统执行。

要安装一次 Puppeteer：

1	npm i -g puppeteer

用法

上述步骤并非绝对必要。当您运行测试场景时，CAS 将在必要时自动尝试安装 Puppeteer。

为了帮助简化测试过程，您可以在 ~/.profile 中使用以下 bash 函数：

function pupcas() {

cd /path/to/cas

scenario=$1

shift 1

./ci/tests/puppeteer/run.sh --scenario ./ci/tests/puppeteer/scenarios/"$scenario" $@}

…稍后可以调用为：

1	pupcas <scenario-name>

要查看可用测试场景的列表，请执行以下操作：

1	./gradlew --build-cache --configure-on-demand --no-daemon -q puppeteerScenarios

远程调试可能在端口 5000 上可用。要成功运行测试，您还需要确保已安装 jq。

测试执行支持以下命令行选项：

旗	描述
--scenario	方案名称，通常以包含测试的文件夹名称建模
--install-puppeteer， --install， --i	安装或更新 Puppeteer 节点模块。
--debug， --d	在启用远程调试的情况下启动 CAS Web 应用程序。
--debug-port， --port	指定远程调试端口，通常为 5000。
--debug-suspend， --suspend， --s	在启动时暂停 CAS Web 应用程序，直到调试器会话连接。
--rebuild， --build	重新构建 CAS Web 应用程序，并忽略以前构建的 WAR 工件。
--dry-run --y	启动测试中配置的 CAS Web 应用程序，而不实际运行测试。
--headless， --h	使用无头浏览器启动测试场景。
--rerun、--resume、--r	启动并假设 CAS 已从上一次尝试开始运行。
--hbo	--headless 和 --build 以及 Gradle 的 --offline 标志的组合。
--hbod	--hbo 和 Gradle 的 --offline 标志的组合。
--bo	--build 和 Gradle 的 --offline 标志的组合。
--hr	--headless 和 --resume 的组合。自动禁用 Linter。
--ho	--headless 和 Gradle 的 --offline 标志的组合。
--hd	--headless 和 --debug 的组合。
--hb	--headless 和 --build 的组合。
--body， --bogy， --boyd	--build、--debug、--dry-run 和 Gradle 的 --offline 标志的组合。
--boy	--build、--dry-run 和 Gradle 的 --offline 标志的组合。
--io， --initonly	初始化测试场景的执行，但不运行它。
--native， --graalvm， --nb	构建测试场景并生成 native-image 作为最终构建工件。
--nr， --native-run	将测试方案作为 native-image 运行。需要通过 --nb 进行本机构建。
--nbr	--nb 和 --nr 标志的组合。
--nl， --no-lint， --nol	禁用验证方案脚本的 Linter。
--hol	禁用 linter 的 --headless 和 --offline 标志的组合。

例如，可以使用以下方法运行具有远程调试器的 login-success 测试方案：

1	pupcas login-success --hbod

所有其他与构建相关的选项和标志（即 --info）都可以直接传递给脚本。

…一旦场景仍在运行，您可以使用以下方法重新运行它（在新的终端窗口中）：

1	pupcas login-success --hr

1. 1. 1. 测试场景剖析

每个测试场景都由以下文件组成：

script.js：执行测试的主驱动程序，通过 Puppeteer 启动无头浏览器。测试脚本的基本轮廓可以是：

const puppeteer = require('puppeteer');const cas = require('../../cas.js');const assert = require("assert");

(async () => {

const browser = await cas.newBrowser(cas.browserOptions());

const page = await cas.newPage(browser);

// Do stuff and check/assert behavior...

await browser.close();})();

script.json：JSON 中的可选测试配置，其中包括必要的 CAS 模块、属性和其他细节。

测试配置的基本简要概述可能是：

{

"dependencies": "module1,module2,module3,...",

"conditions": {

"docker": "true"

"environmentVariables": [

"NAME=VALUE"

"requirements": {

"graalvm": {

"build": false

"docker": {

"build": false

}

"properties": [

"--cas.server.something=something"

"jvmArgs": "...",

"server": "tomcat|jetty|undertow|...",

"SPRING_APPLICATION_JSON": {},

"bootstrapScript": "${PWD}/ci/tests/puppeteer/scenarios/${SCENARIO}/bootstrap.sh",

"initScript": "${PWD}/ci/tests/puppeteer/scenarios/${SCENARIO}/init.sh",

"readyScript": "${PWD}/ci/tests/puppeteer/scenarios/${SCENARIO}/ready.sh",

"exitScript": "${PWD}/ci/tests/puppeteer/scenarios/${SCENARIO}/exit.sh",

"instances": 2,

"instance1": {

"properties": [ ]

"instance2": {

"properties": [ ]

"variations": [

{

"properties": [

]

}

]}

测试 JSON 配置中唯一需要的位可能是 dependencies 属性。

1. 1. 1. MacOS 防火墙弹出窗口

要允许防火墙接受 MacOS 上 Chromium 的传入网络连接，您可以应用以下命令：

1 2	chromium="/path/to/cas/ci/tests/puppeteer/node_modules/puppeteer/.local-chromium"sudo codesign --force --deep --sign - "${chromium}/mac-*/chrome-mac/Chromium.app"

1. 1. 持续集成

单元测试和集成测试由 CAS CI 系统 GitHub Actions 自动执行。

项目
1. PCM公司
  1. 项目管理委员会

CAS 由以 Apache 风格的 PMC 为蓝本的项目管理委员会（PMC）管理。所有与 PMC 相关的事务，包括成员的新提名都必须在邮件列表中进行。

1. 1. 成员

PMC 目前的核心成员是：

Misagh Moayyed [主席]

杰罗姆·勒勒

哈尔·戴德曼

名誉成员是：

比尔·汤普森

丹尼尔·弗雷特

特拉维斯·施密特

德米特里·科皮连科

帖木儿杜尔

斯科特·巴特尔

杰夫·西特勒

安德鲁·佩特罗

朱利安·侯

罗伯特·奥施瓦尔德

马文·艾迪生

1. 1. 结构

PMC 由成员和一名主席组成，主席对委员会拥有执行权，并向 Apereo 董事会报告。主席行使的最常见权力是根据需要任命额外的 PMC 成员。因此，主席可以引导委员会。董事会可以在极端情况下（即功能障碍、已解散）任命一名主席，但该主席通常由 PMC 投票任命。对官方项目源代码存储库具有提交访问权限的 CAS 项目开发人员自动成为 PMC 成员;因此，提交者是 PMC 成员。PMC 主席可能是也可能不是提交者。

1. 1. 投票

所有投票必须在项目邮件列表上进行至少 72 小时;应为特殊情况分配更多时间，例如节假日和其他大量 PMC 成员离线时间可能比正常时间更长的情况。投票是通过惰性共识进行的，其中至少两票 +1 票足以向前推进，而一票 -1 票足以阻止提案。投票应该争取达成共识。

所有 PMC 成员的投票都是平等的;主席没有否决权。

1. 1. 1. 时间跨度

投票是在两个 +1 或一个 -1 后停止，还是在投票期结束之前才统计？

投票开放至少 72h。任何措施实际上都以 -1 票结束，因此如果在投票开始后一分钟内出现 -1，那么再等待就没有意义了。72h窗口的价值在于它为异议者提供了更多时间。投票过程旨在强调和产生共识，这是最重要的方面。

1. 1. PMC 主席提名

PMC 主席的提名需要投票：需要 +1 的多数票，而不是 -1。投票必须在 cas-pmc 邮件列表上私下进行。弃权的会员只是通过懒惰共识被视为支持投票。

1. 1. 提交者提名

提交者的提名需要投票：需要 +1 的多数票，而不是 -1。投票必须在 cas-pmc 邮件列表上私下进行。投票由当前提交者之一提议。社区的所有成员都有权成为提交者，完全基于精英管理。弃权的会员只是通过懒惰共识被视为支持投票。

1. 1. 通信

通信主要通过公共邮件列表进行。例外情况是需要谨慎或保密的问题;在这些情况下，个人分发名单是合适的渠道。根据需要，还可以通过其他适当的渠道进行通信，例如视频/语音电话会议、IRC 和 IM。除了在项目邮件列表上投票外，不得通过任何其他方式做出正式决定;如果它没有发生在 List 上，它就没有发生。在 IRC 和 IM 等副频道中进行的讨论应该在可能影响决策过程时在邮件列表中进行总结。委员会应努力通过高带宽同步媒介定期召开会议，例如在会议上举行面对面会议或语音/视频电话会议。

1. 1. 义务

PMC 成员同意遵守并执行 Apereo 基金会法律政策和基金会品牌/营销政策。PMC 成员应通知打算离开或不活跃，以便于更换或招募新成员。

1. 安全漏洞响应
  1. 安全漏洞响应

CAS应用程序安全涉及的成员：

以Apereo CAS服务器、协议和各种CAS客户端为重点，积极提高CAS的安全性。

响应潜在漏洞并创建、维护和执行漏洞分类和通知策略，部署来自Apereo安全部门的切换等。

发布漏洞报告并努力协调变通办法并修复对出现的安全问题的响应。

生成帮助潜在CAS采用者评估CAS作为开源产品和他们打算实施产品的安全性的工件。这包括威胁建模、数据流图等。

围绕强化、配置、故障安全、默认安全等创建和维护CAS实施的良好实践建议。

要查看应用程序安全工作组的旧档案，请参阅本指南。

1. 1. 上下文和定义

什么是安全漏洞？如何以及何时发现的缺陷可能被标记为漏洞？

安全漏洞几乎总是软件缺陷，通常是CAS部署以意外方式运行的直接结果，尽管系统配置和应用程序状态正确。正确性和意图通常是根据可用的CAS留档或作为主题专家的项目/社区成员来判断的，他们可能能够澄清预期的、预期的行为。由于CAS错误配置、误用或对功能和用例如何工作的误解而出现的安全错误和漏洞不符合条件。同样，源于似是而非的可否认性的场景（即“我不知道X是这样工作的”）通常不符合条件。虽然功能和增强总是可以被审查和讨论，以消除或提高一定程度的灵活性，项目留档也总是可以进一步改进以澄清预期的行为，但缺乏理解或故意滥用几乎总是被视为正常的缺陷或改进的机会。非常欢迎您做出贡献。

此外，在一个涉及许多移动和可变部分的生态系统中，CAS项目通常倾向于只关注CAS部分，并且不会认真声明或尝试保护（甚至有时解释或记录）其部署环境中存在的系统的行为，特别是当这些系统不受CAS拥有、管理或控制并且被视为完全外部时。例如，如果您正在管理由Hazelcast Enterprise支持的集群CAS部署，该部署位于代理前面、负载均衡器后面、连接到Active Directory并通过Docker和库伯内特斯部署，CAS安全性只能达到CAS本身。你是，独立和单独的，负责管理和保护生活在这个生态系统中的所有其他外部组件。您的代理可能允许不受信任的数据通过，或者您的LDAP目录可能支持不安全的连接，或者您可能故意配置CAS接受来自这个星球及其他地方的任何应用程序的authenticationrequests。这些都不构成CAS安全漏洞。

如果您发现CAS留档的各个方面可以得到改进，以更好地澄清和解释特定情况，非常欢迎您提供意见。

1. 1. 响应模型

安全问题通过适当的邮件列表私下报告给CAS。

项目成员承认这个问题，并在内部和私下与记者合作，以确定这个问题的优点。

修复程序作为直接提交到代码库被计划、生成和私下提供。

项目成员或原始报告者应该验证并确认生成的补丁确实解决了问题。

发布安全或补丁版本以供公众使用。

列表礼仪

CAS要求您不要创建公开可见的问题或帖子来解决问题。制造恐慌和混乱是没有意义的。所有社区成员都应该忽略所有此类公开公告和报告。

1. 1. 依赖升级

考虑到规划和发布安全补丁以及披露问题、沟通描述、意图、攻击窗口和修复等所涉及的工作量，通常最好保留安全版本，用于根据特定用例实际可以复制的问题，或者那些真正在实践中以真实方式影响CAS软件内部工作的问题。如果您在某个时候可以有这样的案例，请务必提供详细信息以重现问题。安全扫描程序、静态代码分析器和影响CAS使用的第三方库的假定漏洞通常不符合条件，除非报告者提供的确凿证据表明影响CAS日常运营的真实、实际问题。此类警告在CAS部署的上下文中通常显得肤浅。通常，最好的做法是在本地升级到安装脚本，或者切换到可能删除此类警告的最新CAS版本。

CAS通常倾向于升级功能（次要）版本和主要版本的依赖项，并且相当频繁地这样做。依赖版本通常不会升级以进行补丁和安全修复，除非如上所述，有确凿的证据证明并要求升级的必要性和努力。如果您有工具、审计报告和流程来扫描您的CAS部署并报告具有已知CVE的库和依赖项，并且您的策略需要在没有此类CVE的情况下构建，我们建议您修改CAS构建以替换、删除、升级或替换受影响的库，并删除您认为最好的警告。请注意，这样做会危及CAS构建和部署的稳定性，并且很可能会使您的升级非常困难，因为您可能会遇到与新版本的各种依赖项和库冲突。

1. 1. 安全赏金

Apereo CAS项目不为发现和报告安全问题提供赏金或奖励。安全报告按原样接收，没有任何保证、保证或任何形式的承诺。

1. 1. 报告格式

当您准备私下向适当的渠道传达安全问题时，请确保您的报告包含足够的诊断数据以加快审查和反馈：

指示表现出看似错误行为的确切CAS版本号。

足够详细地描述您的部署/开发环境。

包括错误日志、调试日志、屏幕截图和其他有用的配置片段。

包括解释如何复制问题的步骤。

包括一个可以在实践中复制问题的覆盖项目。

如果可能，准备和共享单元/集成测试以重新创建问题。

记住

确保您的报告呈现自动化、孤立和可重现的测试，以证明安全问题。这是必须的。要求手动验证步骤的轶事描述性证据，即“去这里，点击这个，键入那个，观看这个，运行那个”等，往往不理想，使得项目很难证明追逐童话故事的时间和资源是合理的。如果您无法以自动化和孤立的方式重现问题，问题很可能是环境特定的或PEBCAK。

在发布可能的安全问题之前，请确保受影响的CAS发布行仍处于维护状态。被视为EOL的版本将不会收到指定项目成员的进一步更新和/或关注。

1. 1. 响应时间

如果您已向适当的渠道和邮件列表发布问题或报告了可能的漏洞，但尚未收到回复，则您的提交很可能与以下列出的类别之一相匹配：

邮件列表和所有其他支持渠道上的活动完全是自愿的。从合同上讲，响应模型不存在紧迫感。如有疑问，请查阅项目许可证以了解更多信息。

报告描述缺乏关于问题的基本细节，或者没有充分遵循建议的格式来证明花费时间和/或资源的合理性。

该报告描述了由不同组织、公司或实体拥有的野生易受攻击的CAS部署。记者不打算向适当的系统所有者报告问题，而是打算向Apereo CAS项目报告此易受攻击的部署。

报告的漏洞是CAS操作员执行的系统错误配置或误用的直接结果。

如果您不想等待项目志愿者找到时间来响应安全问题和报告，请考虑与Apereo商业服务/支持提供商谈判专业支持协议，特别是如果您的组织的生计和声誉取决于成功和安全的Apereo CAS部署。

1. 1. 修复时间

如上所述，请记住，邮件列表和所有其他支持渠道上的活动完全是自愿的。响应模型中没有官方含义或紧迫感，因此，潜在安全问题的修复100%取决于个人的可用性和意愿。我们强烈建议您研究项目许可证以获取有关此事的更多信息。如果您对合同义务、SLA和基于计算的紧急程度的响应模型感兴趣，请考虑与Apereo商业服务/支持提供商谈判专业支持协议。

1. 1. 安全修复

CAS应用程序安全小组鼓励所有报告者不仅包括重现和验证报告问题的说明和步骤，还包括并提出补丁文件形式的修复，这些补丁文件在同一问题报告中与小组私下共享。大多数（如果不是全部）应用于CAS代码库的安全修复，无论贡献类型如何（即直接开发人员提交或外部贡献），几乎总是私下进行的。补丁的修复和应用程序的详细信息是私下保存的，不会在公共提交日志中公开，直到到期。以公开可见的拉取请求形式的安全修复和贡献会自动关闭，并向贡献者发出谨慎的警告，以遵循正当程序以正确应用和验证补丁修复。

1. 1. CVE

CAS项目在处理安全问题时不请求或提供CVE。如果您需要获得CVE以证明计划外升级等的合理性，这是一项必须完全由您处理的任务。一般来说，CAS项目比任何CVE采购流程更快地宣布和披露安全问题；我们根本不能延迟安全通知和公告，只要它可能需要接收CVE。

如果你想自愿成为CVE创建过程的核心人物，请一定要大声说出来。

1. 1. 社区通知

一旦安全版本可用，可能会遵守以下过程：

社区成员会收到有关发布可用性的通知。

通知消息应该讨论：

一般而言，安全问题只提供了足够的细节来引起关注和引起社区的注意，但没有造成混乱或为对手创造利用该问题的机会。

安全问题的严重性和补丁发布的性质。

受影响的CAS版本

补丁升级和应用的推荐指南。

在宽限期结束时（见下文），将发布公共安全公告，该公告应充分披露安全补丁或变通方法的问题和细微差别。

小心点

冒着陈述显而易见的风险，请记住只注意并接受来自受信任项目联系人和成员的关于安全修复的社区通知。应该完全忽略来自随机人员的详细安全修复的帖子。

安全公告、通知和详细信息通常发布在Apereo博客上。

1. 1. 宽限期

一旦安全版本发布并且安全漏洞的初始版本公开，CAS将观察到四周的宽限期，以允许社区成员和部署人员过渡和升级到安全版本。在此期间，不会公开有关安全问题的其他详细信息（即重现步骤、严重性和影响等），并且会私下保存对代码库的修复和提交。因此，与安全修复相关的所有发布标签和对CAS代码库的其他修改都将被搁置，直到宽限期结束。在宽限期结束时，有关安全漏洞的详细信息将被公开，然后将实际的补丁、提交和发布标签推送到CAS代码库，供所有人使用。

GitHub通知

GitHubto向那些在GitHub上观看Apereo CAS存储库的人发送的发布通知只能在标记提交公开后发送一次。因此，宽限期尚未到期且标签保持私密的安全释放不会触发来自GitHub的通知。一旦宽限期过去并公开详细信息，标记提交将出现在GitHub上并发送发布通知。

例如，让我们假设最近的CAS安全版本6.6.1.X现已发布。然后通常观察以下过程和时间表：

版本	发布日期	宽限期结束	二进制版本可用性	源代码可用性	GitHub通知
6.6.1.X	七月十号	八月十日	七月十号	八月十日	八月十日

如果您从源代码构建CAS代码库，而不是依赖已发布的二进制版本，您当然应该注意到上述策略对您的构建和发布周期有直接影响，并可能对您的安全状况产生负面影响。鉴于源代码级更改仅在宽限期结束后才会出现在存储库中，这实际上意味着在安全发布的情况下，您将始终至少落后四周，这可能是也可能不是理想的。

此外，安全版本（以及所有其他类型的CAS版本）总是向前滚动。也就是说，CAS安全版本6.6.1.X+1包含6.6.1.X、6.6.1.X-1、6.6.1.X-2以及该版本之前的所有其他内容。安全版本不是孤立产生的。

1. 1. 可信联系人

请注意，CAS项目不能在没有首先验证个人身份和Apereo基金会成员身份的情况下向个人披露有关安全问题及其影响的详细信息。如果您认为自己是您的机构的受信任联系人，并且已由Apereo基金会注册和审查，请向该项目提供足够的背景信息，以便我们可以在放松和受信任的环境中愉快地继续解释详细信息。如果您还不是受信任的成员，请在宽限期内耐心等待，并允许其他受信任的联系人在问题向更广泛的用户社区公开披露之前适当和安全地采取行动来补救问题。

要了解更多关于如何成为Apereo基金会会员和注册可信联系人的信息，请直接联系Apereo。

1. 1. EOL版本

在发布可能的安全问题之前，请确保受影响的CAS发布行仍处于维护状态。被视为EOL的版本将不会收到指定项目成员的进一步更新和/或关注。请记住，如果您的CAS版本未在安全发布公告中列出或影响，并且不再是根据CAS维护策略的活动维护周期的一部分，那么最好的行动方案将是升级到community-maintained的CAS版本。该项目不努力评估、验证、修补或测试软件的EOL版本，对此没有兴趣、地位或预算，也不产生任何声明来确定EOL CAS版本中安全缺陷的严重性或影响。虽然这一规则可以在罕见和极端情况下根据问题的安全性和社区地位进行修改，但一般政策允许一个人不能说死者的坏话。

发布

Releases · apereo/cas · GitHub

支持
1. 支持

CAS 是开源软件，主要由开放友好的社区提供支持。我们首屈一指的免费支持渠道是主要通过邮件列表进行调解的社区讨论。

1. Apereo 基金会会员资格

Apereo 基金会是新泽西州的一家非股份制非营利性公司，其成员来自四大洲的各行各业和行业部门。它的使命是通过开发和维护开源软件来帮助教育机构实现其使命。成为 Apereo 基金会会员，即表示您 –

确保为您依赖的软件提供支持。您的会费用于确保有效的许可、知识产权管理实践、基础设施支持、社区协调、外展等。

让您的机构对 Apereo 的运营方式及其设定优先事项有发言权。您所在机构在 Apereo 基金会董事会的选举中拥有投票权，该董事会为基金会提供战略领导。

能够访问 Apereo 孵化计划等计划。您认为软件项目满足高等教育需求吗？Apereo 是寻找合作伙伴并向其他已经发展社区以维持软件的人学习的地方。

成为同行社区的一员 - 一个由教育机构组成的全球网络，共同解决共同的问题和共同的问题 - 有很多参与机会。

有关组织会员会费和费用的更多信息，请参阅此页面。有关个人会员计划的信息，请参阅 Friends of Apereo。

1. 付费/商业支持

CAS 的商业支持由以下实体提供：

1. 免费/社区支持

请按照以下步骤从 CAS 用户社区获得支持。

社区礼仪

请记住，邮件列表和所有其他支持渠道上的活动完全是自愿的。没有 SLA。没有任何保证。如果无法接受，您可以选择与 Apereo 商业服务提供商签订专业支持协议。此外，除非明确要求，否则请避免直接联系各个项目成员。

1. 聊天室

Apereo 有一个官方的 Slack 聊天工作区，您可以在其中找到#cas 频道。注册页面可在此处找到。特定的 cas 标签也可用于 StackOverflow。

1. 邮件列表

CAS 社区讨论邮件列表是一个中等流量的列表，问题通常在几分钟内得到解答，通常在几天内得到解决。CAS 开发人员会监视该列表并经常参与讨论。请参阅 Mailing Lists 页面了解订阅和礼仪。

1. 会议

Apereo 基金会（前身为 Jasig）提供了许多会议，这些会议提供了许多与高等教育相关的软件产品（包括 CAS）的演示和培训。会议是加强与更大的 CAS 社区和相关开源软件生态系统联系的绝佳场所。

邮件列表
1. 邮件列表

CAS 项目有许多主题邮件列表（现在在 apereo.org 域下），可用于获得支持或参与 CASdevelopment。

需要注意的是，虽然 CAS 拥有国际观众，但讨论以英语进行。社区非常理解非英语母语人士，并且通常会在这些情况下保持耐心和毅力。请用英文发布。

1. CAS 社区列表（cas-user@apereo.org）

重点：支持、故障排除、一般问题。

如果您对 CAS 的安装、配置或故障排除有疑问，请发布到此列表。

查看和/或订阅

旧档案

列表礼仪

如果您的问题不包含足够的数据并且描述模糊，则可能会被忽略。请尽量精确。

1. 1. 数据，数据，数据

请始终确保报表中有足够的诊断数据：

您是否报告了表现出看似错误行为的确切 CAS 版本号？

您是否足够详细地描述了您的部署/开发环境？

您是否包含了错误日志、调试日志、屏幕截图和配置的其他有用片段来演示问题？

您是否包含了解释如何重复问题的步骤？

您是否准备了单元测试来重现问题？

您是否准备了一个可能允许该项目复制问题的覆盖项目？

请记住：

“It doesn't work” 不起作用。分享尽可能多的信息。

换句话说;您案例的读者不一定在您的脑海中！他们不知道你知道什么。帮助他们。您想回复自己的报告吗？

1. 1. 要有耐心

一旦您发布到邮件列表，请耐心等待并允许成员阅读您的帖子并回复。快速连续提交或同时发送到多个邮件列表的邮件最终将被邮件服务器视为垃圾邮件，发件人将被阻止。请记住，邮件列表上的所有活动都是完全自愿的。没有 SLA。如果您发现邮件列表的回复不够快，您可以寻求其他支持选项。

如果您发现您的消息没有及时到达邮件列表，请联系项目成员和/或 Apereo 以解决问题。

1. 1. 保持好奇

研究问题并确保进行尽职调查：

您是否扫描了 Web 档案中的类似案例？

您是否查看了该项目的文档以找到更好的解释？

您是否查看了项目的邮件列表、聊天室和其他工具以找到可能的解决方案？

您是否考虑过升级到最新的维护版本以查看问题是否已修复？

您是否查看了 DEBUG 日志，看看该软件是否可以提供解释？

1. 1. 贡献

记得

如果您已经发现了增强功能或错误，强烈建议您只提交拉取请求来解决该问题。无需特别的仪式来创建单独的问题。拉取请求是问题，它将按此方式进行跟踪和标记。

如果可以的话，请始终自愿发布补丁并制定解决方案。请准备好跟进以在您的环境中测试生成的补丁，并始终尝试提供确认。简单地抱怨某件事并让它放在问题跟踪器中让其他人处理不会给你带来太多好处。如果您发现您认为值得其他人花时间为您解决的问题，请务必证明该问题首先也值得您自己花时间。“如果这对你来说不是问题，那对我来说也不是问题”，诸如此类。

如有疑问，请查阅项目 Apache v2 许可证：

除非适用法律要求或书面同意，否则根据本许可分发的软件将按“原样”分发，不附带任何明示或暗示的保证或条件。请参阅许可证，了解许可证下管理权限和限制的特定语言。

列表礼仪

除非明确要求，否则请避免直接联系各个项目成员。