多维系统下单点登录的技术深入详解

2024-08-27 10:36
文章标签 技术 详解 登录 深入 单点 多维系统

本文主要是介绍多维系统下单点登录的技术深入详解，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

书接上回，上一篇讲到了单点登录的整体解决方案，今天我们一起看看单点登录技术方面内容。

1、基于SAML实现的统一认证

1、概述

SAML 2.0 用来在安全域中交换身份验证（Authentication）数据和 授权（Authorization）数据。

SAML 2.0基于XML协议，使用包含断言（Assertions）的安全令牌在SAML授权方（即身份提供者IdP）和SAML消费方（即服务提供者SP）之间传递委托人（终端用户）的信息。SAML 2.0 可以实现基于网络跨域的单点登录(SSO)， 以便于减少向一个用户分发多个身份验证令牌的管理开销。

2、断言

断言是一个包含了由SAML授权方提供的0到多个声明（statement）的信息包。SAML断言通常围绕一个主题生成。该主题使用声明。SAML 2.0规范定义了三种断言声明，详细信息如下：

  • 身份验证（Authentication）：该断言的主题是在某个时间通过某种方式被认证。

  • 属性（Attribute）：该言的主题和某种属性相关联。

  • 授权决策（Authorization Decision）：该断言的主题被允许或者被禁止访问某个资源。

断言举例：

<saml:Assertion
xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
ID="b07b804c-7c29-ea16-7300-4f3d6f7928ac"
Version="2.0"IssueInstant="2004-12-05T09:22:05Z">
<saml:Issuer>https://idp.example.org/SAML2</saml:Issuer>
<ds:Signature
xmlns:ds="http://www.w3.org/2000/09/xmldsig#">...</ds:Signature>
<saml:Subject>
<saml:NameID
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient">
3f7b3dcf-1674-4ecd-92c8-1544f346baf8
</saml:NameID>
<saml:SubjectConfirmation
Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
<saml:SubjectConfirmationData
InResponseTo="aaf23196-1773-2113-474a-fe114412ab72"
Recipient="https://sp.example.com/SAML2/SSO/POST"
NotOnOrAfter="2004-12-05T09:27:05Z"/>
</saml:SubjectConfirmation>
</saml:Subject>
<saml:Conditions
NotBefore="2004-12-05T09:17:05Z"
NotOnOrAfter="2004-12-05T09:27:05Z">
<saml:AudienceRestriction>
<saml:Audience>https://sp.example.com/SAML2</saml:Audience>
</saml:AudienceRestriction>
</saml:Conditions>
<saml:AuthnStatement
AuthnInstant="2004-12-05T09:22:00Z"
SessionIndex="b07b804c-7c29-ea16-7300-4f3d6f7928ac">
<saml:AuthnContext>
<saml:AuthnContextClassRef>
urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport
</saml:AuthnContextClassRef>
</saml:AuthnContext>
</saml:AuthnStatement>
<saml:AttributeStatement>
<saml:Attribute
xmlns:x500="urn:oasis:names:tc:SAML:2.0:profiles:attribute:X500"
x500:Encoding="LDAP"
NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:uri"
Name="urn:oid:1.3.6.1.4.1.5923.1.1.1.1"
FriendlyName="eduPersonAffiliation">
<saml:AttributeValue
xsi:type="xs:string">member</saml:AttributeValue>
<saml:AttributeValue
xsi:type="xs:string">staff</saml:AttributeValue>
</saml:Attribute>
</saml:AttributeStatement>
</saml:Assertion>

它主要是用来实现Web浏览器的单点登录。该断言包括一个身份验证断言 saml:AuthnStatement 和一个属性断言saml:AttributeStatement，SP将使用该属性断言实现访问控制。

3、工作流程

SAML 认证流程一般都会牵涉到两方：服务提供方（SP）和身份提供方（IdP），典型的 SP 有阿里云、腾讯云以及很多很多的 SaaS 服务；IdP 其实就是我们企业自己，因为用户目录在我们这里。

访问 SP 服务的时候，SP 会向 IdP 发送一个 SAML Request（具体是什么我们暂时不关心），请求 IdP判断用户身份。IdP 收到 SAML Request 后，可以通过某种手段对用户身份进行认证，如果已登录，可以直接返回用户身份信息给 SP；如果未登录，可以弹出一个登录框，用户登录之后再将用户身份返回给 SP。SP 收到用户信息之后，再在自己的数据库里面找出对应的用户，然后以这个用户的身份访问 SP服务。

image-20240826171739191

  1. 用户通过浏览器访问网站（SP），网站提供服务但是并不负责用户认证。

  2. SP 向 IDP 发送了一个 SAML 认证请求，同时 SP 将 用户浏览器 重定向到 IDP。

  3. IDP 在验证完来自 SP 的合法请求， 在浏览器中呈现登陆表单让用户填写用户名与密码信息，进行登陆。

  4. 用户登陆成功， IDP 会生成一个包含用户信息的 SAML token（SAML token 又称为 SAMLAssertion，本质上是 XML 节点）。IDP 向 SP 返回 token，并且将 用户重定向 到 SP。

  5. SP 对拿到的 token 进行验证，并从中解析出用户信息，例如用户是谁以及用户的权限有哪些。此时可以根据这些授权信息允许用户访问我们网站的内容。

4、授权机制

SAML 只是认证协议，自身并不提供授权功能， 可以通过XACML实现授权。

XACML 是可扩展访问控制标记语言，以XML的形式描述策略语言和授权决策请求/响应，提供管理授权决策的语法。

SAML 和 XACML 结合实现权限访问控制，映射关系：

image-20240826171836972

SAML 和 XACML 结合控制应用模型：

image-20240826171847487

该模型是一个完整的访问控制体系结构，包含身份验证和授权两部分。身份验证可 以接受来自其它系统的各种安全令牌，包括 SAML 断言，对请求主体进行验证并产生 SAML 身份验证断言。只要合作的第三方服务联合信任，就可以实现 服务的安全交互以及用户 的单点登录。

模型的授权基于 PMI 统一授权管理体系，授权系统向 AA（属性权威机构）请 求关于 Web 服务请求主体的属性信息，AA 实现 SAML 接口，返回 SAML 属性断言。模型使用统一的策略语言 XACML，由 SAML 为其提供底层传输机制，适用于各种类型的访问 控制系统。策略可以被不同的应用使用，使策略的管理更加容易。

5、应用场景

目前SAML广泛应用于云服务的认证，比如阿里云、AWS和腾讯云等，在云服务上面维护统一的用户信息进行身份认证。SAML认证一般分为两部分，用户池与角色身份池。

用户池可以让应用程序接入，也可以通过第三方身份提供商 (IdP) ，对用户身份进行认证。角色身份池可以通过凭证来控制访问云服务资源，比如阿里云推送服务，Amazon S3 和 DynamoDB等。

以AWS的Amazon Cognito为例，简单介绍下它的应用：

通过SAML协议验证用户身份，然后授予用户访问其他AWS 服务的权限。

  1. 在第一步中，您的应用程序用户通过用户池登录，并在成功进行身份验证后收到用户池令牌。

  2. 接下来，您的应用程序通过用户池令牌交换 AWS 凭证。

  3. 最后，您的应用程序用户可以使用这些 AWS 凭证来访问其他 AWS 服务（如 Amazon S3 或DynamoDB）。

image-20240826172400680

6、AWS云服务接入方案

用户池进行身份验证

image-20240826172153189

用户使用用户池进行身份验证。应用程序用户可以通过用户池直接登录，也可以通过第三方身份提供商 (IdP) 联合。用户池管理从通过 Facebook、Google、Amazon 和 Apple 进行的社交登录返回的以及从 OpenID Connect (OIDC) 和 SAML IdP 返回的令牌的处理开销。

成功进行身份验证后， Web 或移动应用程序将收到来自 Amazon Cognito 的用户池令牌。可以使用这些令牌检索允许的应用程序访问其他 AWS 服务的 AWS 凭证，也可以选择使用它们来控制对您的服务器端资源或 Amazon API Gateway 的访问。

用户池访问服务器端资源

用户池登录后，Web 或移动应用程序将收到用户池令牌。可以使用这些令牌控制对服务器端资源的访问。可以创建用户池组来管理权限以及表示不同类型的用户。

image-20240826173058386

用户池和身份池访问云服务

用户池登录认证成功之后，获取返回的令牌，再通过令牌换取身份池的信息，拿去身份池信息就可以访问其他的云服务资源。

image-20240826173215612

支持第三方进行身份验证并使用身份池访问云服务

身份池需来自第三方身份提供商，进行身份验证之后， 返回用户的 IdP 令牌。再通过令牌交换获取云服务的身份池信息，身份池将授予可用来访问其他云服务的临时凭证。

image-20240826173232379

更多资料参照官方文档：Amazon Cognito 教程

7、阿里云接入方案

阿里云支持基于SAML 2.0的SSO（Single Sign On，单点登录），也称为身份联合登录。阿里云提供以下两种基于SAML 2.0协议的SSO方式：

**用户SSO：**阿里云通过IdP颁发的SAML断言确定企业用户与阿里云RAM用户的对应关系 。企业用户登录后，使用该RAM用户访问阿里云。

**角色SSO：**阿里云通过IdP颁发的SAML断言确定企业用户在阿里云上可以使用的RAM角色。企业用户登录后，使用SAML断言中指定的RAM角色访问阿里云。请参见进行角色SSO。

用户SSO

image-20240826173412005

当管理员在完成用户SSO的相关配置后，可以通过以下流程来实现用户SSO。

  1. Alice使用浏览器登录阿里云，阿里云将SAML认证请求返回给浏览器。

  2. 浏览器向IdP转发SAML认证请求。

  3. IdP提示Alice登录，并在Alice登录成功后生成SAML响应返回给浏览器。

  4. 浏览器将SAML响应转发给SSO服务。

  5. SSO服务通过SAML互信配置，验证SAML响应的数字签名来判断SAML断言的真伪，并通过SAML断言的NameID元素值，匹配到对应阿里云账号中的RAM用户身份。

  6. SSO服务向浏览器返回控制台的URL。

  7. 浏览器重定向到阿里云控制台。

角色SSO

image-20240826173456241

  1. 企业员工Alice可登录到阿里云，使用浏览器在IdP的登录页面中选择阿里云作为目标服务。

  2. IdP生成一个SAML响应并返回给浏览器。

  3. 浏览器重定向到SSO服务页面，并转发SAML响应给SSO服务。

  4. SSO服务使用SAML响应向阿里云STS服务请求临时安全凭证，并生成一个可以使用临时安全凭证登录阿里云控制台的URL。

  5. SSO服务将URL返回给浏览器。

  6. 浏览器重定向到该URL，以指定角色身份登录到阿里云控制台。

更多资料参照官方文档：阿里云SSO

2、基于OAuth实现的统一认证

1、概述

OAuth2 实质是为第三方应用颁发一个具有时效性的Token令牌，使其他服务或第三方应用能够通过令牌获取相关资源。 常见的场景：

比如进入某个网站没有账号信息， 但可以通过QQ、微信、支付宝等账号进行登陆， 在这个登陆过程中采用的就是Oauth2协议； OAUTH2不仅支持认证，还具备授权功能， 比如通过QQ登录获取用户头像，基本资料等。

2、角色

  • resource owner : 资源所有者，具备访问该资源的实体， 如果是某个人， 被称为end-user。
  • resources server: 资源服务器，受保护的资源服务器， 具备提供资源能力， 如订单服务， 商品服务等。
  • client: 客户端，这并不是指用户， 而是对资源服务器发起请求的应用程序，比如前后分离项目，前端服务访问管理接口， 访问后台业务功能接口。
  • authorization server: 授权服务器， 能够给客户端颁发令牌， 这个就是我们上面所讲的统一认证授权服务器。
  • user-agent: 用户代理， 作为资源所有者与客户端沟通的工具， 比如APP， 浏览器等。

3、协议流程

OAuth2包含四种授权模式：

  1. 授权码模式
  2. 隐式/简化授权模式
  3. 密码模式
  4. 客户端模式

image-20240826173818029

  1. Resource Owner 与 Client 之间 ， 资源所有者向Client发起认证请求， Client再返回认证授权信息。

  2. Client 收到 Resource Owner 的认证请求后， 会去Authorization Server 申请访问令牌，Authorization Server会让Client 进行认证，

通过之后会返回Access Token。

  1. Client 拿到 Authorization Server 的 Acceess Token , 访问Resource Server，Resource Server验证之后， 返回被保护的资源信息。

  2. Resource Server 可以通过JWT在本地进行验证， 也可以访问 Authorization Server， 对Client 的请求的合法性进行验证。

4、OAuth2 授权码模式

image-20240826173901360

  1. 客户端携带 client_id, scope, redirect_uri, state 等信息引导用户请求授权服务器的授权端点下发code。

  2. 授权服务器验证客户端身份，验证通过则询问用户是否同意授权（此时会跳转到用户能够直观看到的授权页面，等待用户点击确认授权）。

  3. 假设用户同意授权，此时授权服务器会将 code 和 state（如果客户端传递了该参数）拼接在redirect_uri 后面，以302(重定向)形式下发 code。

  4. 客户端携带 code, redirect_uri, 以及 client_secret 请求授权服务器的令牌端点下发access_token。

  5. 授权服务器验证客户端身份，同时验证 code，以及 redirect_uri 是否与请求 code 时相同，验证通过后下发 access_token，并选择性下发 refresh_token，支持令牌的刷新。

示例说明

  1. 授权请求

    response_type=code // 必选项
&client_id={客户端的ID} // 必选项
&redirect_uri={重定向URI} // 可选项
&scope={申请的权限范围} // 可选项
&state={任意值} // 可选项

  2. 授权响应参数：

code={授权码} // 必填
&state={任意文字} // 如果授权请求中包含 state的话那就是必填
  1. 令牌请求：
grant_type=authorization_code // 必填
&code={授权码} // 必填 必须是认证服务器响应给的授权码
&redirect_uri={重定向URI} // 如果授权请求中包含 redirect_uri 那就是必填
&code_verifier={验证码} // 如果授权请求中包含 code_challenge 那就是必填
  1. 令牌响应：3.2.5 OAuth2
"access_token":"{访问令牌}", // 必填
"token_type":"{令牌类型}", // 必填
"expires_in":{过期时间}, // 任意
"refresh_token":"{刷新令牌}", // 任意
"scope":"{授权范围}" // 如果请求和响应的授权范围不一致就必填

5、OAuth2 隐式简化模式

image-20240826175956304

  1. 资源拥有者（用户）通过代理（WEB浏览器）访问客户端程序，发起简化模式认证。

  2. 客户端（Client）向认证服务器（Auth Server）发起请求， 此时客户端携带了客户端标识（client_id）和重定向地址（redirect_uri）。

  3. 客户端（Client）拿到令牌 token 后就可以向第三方的资源服务器请求资源了。

示例说明

1、授权请求：

response_type=token // 必选项 
&client_id={客户端的ID} // 必选项 
&redirect_uri={重定向URI} // 可选项 
&scope={申请的权限范围} // 可选项 
&state={任意值} // 可选项

2、授权响应参数：

&access_token={令牌信息} // 必填 
&expires_in={过期时间} // 任意 
&state={任意文字} // 如果授权请求中包含 state 那就是必填 
&scope={授权范围} // 如果请求和响应的授权范围不一致就必填

思考：为什么要有授权码和简化模式？看完这两种模式， 可能会有些疑问， 为什么要这么麻烦， 直接一次请求返回TOKEN不就可以吗？
我们可以看出， 两者主要差别， 是少了code验证环节， 直接返回token了， code验证是客户端与认证服务器在后台进行请求获取， 代理是获取不到TOKEN的， 如果缺少这个环节， 直接返回TOKEN， 相当于直接暴露给所有参与者， 存在安全隐患， 所以简化模式，一般用于信赖度较高的环境中使用。

6、密码模式

image-20240827001439132
  1. 资源拥有者直接通过客户端发起认证请求。
  2. 客户端提供用户名和密码， 向认证服务器发起请求认证。
  3. 认证服务器通过之后， 客户端（Client）拿到令牌 token 后就可以向第三方的资源服务器请求资源了。

示例: 1. 令牌请求

grant_type=password // 必填 
&username={用户ID} // 必填 
&password={密码} // 必填 
&scope={授权范围} // 任意 12345
  1. 令牌响应：
"access_token":"{访问令牌}", // 必填 
"token_type":"{令牌类型}", // 必填 
"expires_in":"{过期时间}", // 任意 
"refresh_token":"{刷新令牌}", // 任意 
"scope":"{授权范围}" // 如果请求和响应的授权范围不一致就必填
12345

此模式简化相关步骤， 直接通过用户和密码等隐私信息进行请求认证， 认证服务器直接返回token，这需要整个环境具有较高的安全性。

7、OAuth2 客户端模式

image-20240827001525564

  1. 此模式最为简单直接， 由客户端直接发起请求。
  2. 客户端与服务器信赖度较高， 服务端根据请求直接认证返回token信息。
  3. 客户端（Client）拿到令牌 token 后就可以向第三方的资源服务器请求资源了。
    这种模式一般在内部服务之间应用， 授权一次， 长期可用， 不用刷新token。

示例:

  1. 令牌请求：
grant_type=client_credentials // 必填 
client_id={客户端的ID} // 必填 
client_secret={客户端的密钥} // 必填 
&scope={授权范围} // 任意
1234
  1. 令牌响应：
"access_token":"{访问令牌}", // 必填 
"token_type":"{令牌类型}", // 必填 
"expires_in":"{过期时间}", // 任意 
"scope":"{授权范围}" // 如果请求和响应的授权范围不一致就必填
1234

8、Spring Security OAuth设计

整体结构设计：

image-20240827001620777

UML类图：

image-20240827001702402

9、增强Token技术解决方案

image-20240827001726937

优势与应用场景
基于Token的鉴权方案，实现方式有多种，增强Token属于其中一种，为什么要采用增强Token方式，它能够解决怎样的问题？ 普通Token认证方式，没有附带必要的用户信息，如果要查询，需要再次调用OAuth2的用户资料认证接口，会增加传输开销；JWT虽然能够附带一定用户信息，但受限于长度，存储空间有限； 如果既要保障性能，又要求能够存储一定的信息，就可以采用增强Token方案，它是将信息存储至Redis缓存中，作为资源服务，接收到Token之后, 可以直接从Redis中获取信息。

它可以适用于微服务架构下，有一定用户信息要求的场景，比如订单服务、资金服务需要获取用户的基本资料，但如果是跨IDC，跨区域，需要暴露外网的情况下，不推荐采用此方案，因为需要保障数据的安全性。

10、JWT技术解决方案

JWT认证流程如下：

image-20240827001816839

JWT应用场景:

  1. 认证 Authentication；
  2. 授权 Authorization // 注意这两个单词的区别；
  3. 联合识别；
  4. 客户端会话（无状态的会话）;
  5. Restful Api 无状态认证。

JWT缺陷:

  1. 更多的空间占用。如果将存在服务端session中的各类信息都放在JWT中保存在客户端，可能造成JWT占用更大空间，需要考虑cookie的空间限制因素，如果放在Local Storage，则可能受到XSS攻击。
  2. 更不安全。这里是特指将JWT保存在Local Storage中，然后使用Javascript取出后作为HTTPheader发送给服务端的方案。在Local Storage中保存敏感信息并不安全，容易受到跨站脚本攻击，跨站脚本（Cross site script，简称xss）是一种“HTML注入”，由于攻击的脚本多数时候是跨域的，所以称之为“跨域脚本”，这些脚本代码可以盗取cookie或是Local Storage中的数据( XSS攻 击的原理解释)。
  3. 无法作废已颁布的令牌。所有的认证信息都在JWT中，由于在服务端是无状态，即使你知道了某个JWT被盗取了，也没有办法将其作废。在JWT过期之前，除非主动增加过期接口，否则无法处理。
  4. 续签问题。传统 session请求时是可以自动续期，payload之中有一个exp过期时间参数，它可以代表JWT的时效性，但JWT自身设计并没有考虑续签问题，因为payload是参与签名处理，如果exp过期时间被修改，那整个JWT串就会产生变化，所以JWT原生并不支持续签。

JWT应用优化方案:

  1. 针对安全性问题： 可以使用Cookie存储， 并设置HttpOnly=true，只能由服务端保存以及通过自动回传的cookie取得JWT，以便防御XSS攻击； 在JWT载体中加入一个随机值作为CSRF令牌，服务端将令牌也保存在Cookie中，前端可以取得该令牌并在请求时作为HTTP header头部信息传递，服务端在认证时，从JWT取出CSRF令牌和HEADER中的令牌做比对，从而防止CSRF的攻击。
  2. 续签问题： 通过Token的Refresh机制来实现，需要对JWT的传递做统一封装，客户端再开辟一个线程定期检测有效期，临近过期时重新刷新Tokens，进行全局更新。JWT扩展知识

JWT扩展知识:

  • JWS(JSON Web Signature):其结构就是在JWT的基础上，在头部声明签名算法，并在最后添加上签名。创建签名，是保证jwt不能被他人随意篡改。为了完成签名，除了用到header信息和payload信息外，还需要算法的密钥，也就是secret。当利用非对称加密方法的时候，这里的secret就是为私钥。

  • JWE(JSON Web Encryption):它能够保护数据不被第三方查看，JWT是通过签名来验证数据来源的合法性，但载体信息只是通过Base64编码，不能严格保障数据的安全性，通过JWE，能够使JWT变得更为安全。

    数据结果类型：

    image-20240827001857872

这篇关于多维系统下单点登录的技术深入详解的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/1111429。

相关文章

Debezium 与 Apache Kafka 的集成方式步骤详解

Debezium 与 Apache Kafka 的集成方式步骤详解

《Debezium与ApacheKafka的集成方式步骤详解》本文详细介绍了如何将Debezium与ApacheKafka集成,包括集成概述、步骤、注意事项等,通过KafkaConnect,D... 目录一、集成概述二、集成步骤1. 准备 Kafka 环境2. 配置 Kafka Connect3. 安装 D
阅读更多...
Java中ArrayList和LinkedList有什么区别举例详解

Java中ArrayList和LinkedList有什么区别举例详解

《Java中ArrayList和LinkedList有什么区别举例详解》：本文主要介绍Java中ArrayList和LinkedList区别的相关资料,包括数据结构特性、核心操作性能、内存与GC影... 目录一、底层数据结构二、核心操作性能对比三、内存与 GC 影响四、扩容机制五、线程安全与并发方案六、工程
阅读更多...
Spring Cloud LoadBalancer 负载均衡详解

Spring Cloud LoadBalancer 负载均衡详解

《SpringCloudLoadBalancer负载均衡详解》本文介绍了如何在SpringCloud中使用SpringCloudLoadBalancer实现客户端负载均衡,并详细讲解了轮询策略和... 目录1. 在 idea 上运行多个服务2. 问题引入3. 负载均衡4. Spring Cloud Load
阅读更多...
Springboot中分析SQL性能的两种方式详解

Springboot中分析SQL性能的两种方式详解

《Springboot中分析SQL性能的两种方式详解》文章介绍了SQL性能分析的两种方式：MyBatis-Plus性能分析插件和p6spy框架,MyBatis-Plus插件配置简单,适用于开发和测试环... 目录SQL性能分析的两种方式:功能介绍实现方式:实现步骤:SQL性能分析的两种方式:功能介绍记录
阅读更多...
在 Spring Boot 中使用 @Autowired和 @Bean注解的示例详解

在 Spring Boot 中使用 @Autowired和 @Bean注解的示例详解

《在SpringBoot中使用@Autowired和@Bean注解的示例详解》本文通过一个示例演示了如何在SpringBoot中使用@Autowired和@Bean注解进行依赖注入和Bean... 目录在 Spring Boot 中使用 @Autowired 和 @Bean 注解示例背景1. 定义 Stud
阅读更多...
如何通过海康威视设备网络SDK进行Java二次开发摄像头车牌识别详解

如何通过海康威视设备网络SDK进行Java二次开发摄像头车牌识别详解

《如何通过海康威视设备网络SDK进行Java二次开发摄像头车牌识别详解》：本文主要介绍如何通过海康威视设备网络SDK进行Java二次开发摄像头车牌识别的相关资料,描述了如何使用海康威视设备网络SD... 目录前言开发流程问题和解决方案dll库加载不到的问题老旧版本sdk不兼容的问题关键实现流程总结前言作为
阅读更多...
SQL 中多表查询的常见连接方式详解

SQL 中多表查询的常见连接方式详解

《SQL中多表查询的常见连接方式详解》本文介绍SQL中多表查询的常见连接方式,包括内连接（INNERJOIN）、左连接（LEFTJOIN）、右连接（RIGHTJOIN）、全外连接（FULLOUTER... 目录一、连接类型图表（ASCII 形式）二、前置代码（创建示例表）三、连接方式代码示例1. 内连接（I
阅读更多...
Go路由注册方法详解

Go路由注册方法详解

《Go路由注册方法详解》Go语言中,http.NewServeMux()和http.HandleFunc()是两种不同的路由注册方式,前者创建独立的ServeMux实例,适合模块化和分层路由,灵活性高... 目录Go路由注册方法1. 路由注册的方式2. 路由器的独立性3. 灵活性4. 启动服务器的方式5.
阅读更多...
Java中八大包装类举例详解(通俗易懂)

Java中八大包装类举例详解(通俗易懂)

《Java中八大包装类举例详解(通俗易懂)》：本文主要介绍Java中的包装类,包括它们的作用、特点、用途以及如何进行装箱和拆箱,包装类还提供了许多实用方法,如转换、获取基本类型值、比较和类型检测,... 目录一、包装类（Wrapper Class）1、简要介绍2、包装类特点3、包装类用途二、装箱和拆箱1、装
阅读更多...
Go语言中三种容器类型的数据结构详解

Go语言中三种容器类型的数据结构详解

《Go语言中三种容器类型的数据结构详解》在Go语言中,有三种主要的容器类型用于存储和操作集合数据：本文主要介绍三者的使用与区别,感兴趣的小伙伴可以跟随小编一起学习一下... 目录基本概念1. 数组（Array）2. 切片（Slice）3. 映射（Map）对比总结注意事项基本概念在 Go 语言中，有三种主要
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2