关于跨域

1.关于跨域:
在这里插入图片描述
跨域其实主要是因为浏览器的同源策略的限制,而服务器之间是没有的,请求只需要ip和端口存在正确即可
协议、域名、端口都相同才叫同源,
同源政策的目的,是为了保证用户信息的安全,防止恶意的网站窃取数据。
同源限制:1)无法读取不同源的 Cookie、LocalStorage 和 IndexDB 。
2)无法获得不同源的DOM 。
假设:平时登录银行,用的www.yinhang.com,现在有一个钓鱼网站,www.yinghang.com,钓鱼网站窃取了正常的网站的DOM,网址也是差不多,一般人是看不出来的。一旦输入了,账号密码,对方只需要console.log(XX),那就危险了!还有就是,如果一个网站,跳另一个网站,cookie允许随意携带,那危险也可想而知。
所以浏览器的同源限制还是很有必要的,不说绝对,但能避免很多潜在危险了!
2.那么当处于开发人员,不得不进行跨域,那又如何应对呢!
其实关于跨域的方法,网上案例很多,可以前端客户端处理,也可以后台服务器配置。
前端操作的:,什么jsonp,iframe等等,作为后端dog就不详细说了,网上应该蛮多
后台服务器配置的普通跨域请求: 只服务端设置Access-Control-Allow-Origin即可,前端无须设置。大部分情况,大家都喜欢将Access-Control-Allow-Origin设置为*,即任意外域都能访问该资源。
附带凭证信息的请求:,需要前后端都要配置
CORS预请求会将用户的身份认证凭据排除在外,包括cookie、http-authentication报头等。如果需要支持用户凭证,需要在XHR的withCredentials属性设置为true,同时Access-control-allow-origin不能设置为*。在服务器端会利用响应报头Access-Control-Allow-Credentials来声明是否支持用户凭证。同时,利用withCredentials这个属性,也可以检测浏览器是否支持CORS。
但是在实践过程中,一般我们喜欢让服务器来多做一些处理,从而尽可能让前端简化,所以这里主要讲了一个,究极简单的,后端服务器,处理跨域问题:
只需要将这个代码在服务器端filter中加入:CorsConfig.java文件即可:这里前端也没做操作,只是允许浏览器的跨域请求,带cookie等身份认证凭据,则前后端都还需要配置

import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.web.cors.CorsConfiguration;
import org.springframework.web.cors.UrlBasedCorsConfigurationSource;
import org.springframework.web.filter.CorsFilter;

/**
 * 跨域配置
 * @author zp
 */
@Configuration
public class CorsConfig {
    private CorsConfiguration buildConfig() {
        CorsConfiguration corsConfiguration = new CorsConfiguration();
        // 允许任何域名使用
        corsConfiguration.addAllowedOrigin("*");
        // 允许任何头
        corsConfiguration.addAllowedHeader("*");
        // 允许任何方法(post、get等)
        corsConfiguration.addAllowedMethod("*");
        return corsConfiguration;
    }

    @Bean
    public CorsFilter corsFilter() {
        UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        // 对接口配置跨域设置
        source.registerCorsConfiguration("/**", buildConfig());
        return new CorsFilter(source);
    }

}

ojbk,以前只知道有这个问题,解决什么的,都是等大佬们配置好,使用即可,今天渐渐去研究了一番,还是可以的!加油,继续写bug,改bug!挺有意思的呢!

<think>嗯,用户想了解身份认证的方法,结合之前的对话历史和系统指令,需要系统整理相关信息。用户引用了多个资料片段,重点提到了Session-Cookie的局限性和JWT的优势,特别是场景下的适用性。从技术角度看,认证的核心痛点是浏览器同源策略对Cookie的限制。Session-Cookie方案在时需要额外配置CORS和withCredentials属性,安全性也容易受CSRF攻击影响。而JWT的无状态特性天然适合,Token可以放在请求头里自由传递,但要注意Token存储安全性和过期机制。用户可能是前端开发者或全栈工程师,正在设计系统认证方案。ta提到的单点登录需求值得重点关注,需要解释JWT如何配合OAuth2实现多系统间的信任传递。引用[3]中提到的统一身份认证场景很典型,应该用SSO方案展开说明。回复结构上先分Session和JWT两类方法,再补充单点登录场景。重点对比两者的实现差异,比如JWT如何解决Cookie问题,以及服务端如何验证Token签名。引用资料时要把参考标记自然地融入说明文字里,比如提到Express框架的使用就可以关联引用[1][4]。用户可能还有隐含需求,比如想了解具体代码实现或性能考量。可以准备回答Session共享方案(Redis集群)、CORS配置细节、JWT加解密开销等问题。</think> 身份认证的常用方法及适用场景如下: --- ### 一、Session-Cookie 方案(需配置) 1. **基本原理** - 服务端存储用户Session,通过Set-Cookie返回Session ID给前端 - 浏览器后续请求**自动携带Cookie**(需开启`withCredentials`) 2. **问题解决** ```java // Spring Boot示例(引用[2]) @CrossOrigin(origins = "https://client-domain.com", allowCredentials = "true") ``` - **必要条件**: - 前端:`axios.defaults.withCredentials = true` - 后端:`Access-Control-Allow-Credentials: true` - 名白名单:`Access-Control-Allow-Origin: https://client-domain.com` 3. **缺点**: - 需服务端维护Session存储 - 配置复杂(引用[1][4]) - CSRF攻击风险 --- ### 二、JWT(JSON Web Token)方案(推荐使用) 1. **核心机制**(引用[1][4]): ```mermaid graph LR A[用户登录] --> B[服务端生成JWT] B --> C[返回Token给前端] C --> D[前端存储Token] D --> E[请求时携带Authorization头] ``` 2. **优势**: - 无状态:服务端不存储会话 - 天然支持:通过HTTP Header传递 - 典型Token格式:`Bearer eyJhbGci...` 3. **Express实现示例**(引用[1]): ```javascript // 生成Token const token = jwt.sign({userId: 123}, 'secretKey', {expiresIn: '2h'}); // 验证中间件 const auth = (req, res, next) => { const token = req.header('Authorization')?.replace('Bearer ', ''); jwt.verify(token, 'secretKey', (err, decoded) => { if(err) return res.status(401).send(); req.user = decoded; next(); }); } ``` --- ### 三、单点登录(SSO)方案(引用[3]) 1. **系统认证流程**: ``` 用户访问A系统 → 重定向至认证中心 → 登录后携带Token返回A系统 → 访问B系统时认证中心自动授权 ``` 2. **关键技术**: - 中央认证服务器 - Token共享(如JWT) - Cookie + OAuth2.0协议 --- ### 四、方案对比表 | **方案** | 复杂度 | 安全性 | 适用场景 | |----------------|------------|------------|------------------------| | Session-Cookie | 高⭐ | 易受CSRF | 同主下的子系统 | | JWT | 低✅ | 需防XSS | API/微服务架构 | | SSO | 中⚠️ | 最高🔒 | 企业级多系统统一认证 | --- **总结建议**: 1. 纯前端调用API → **优先JWT方案**(引用[4]) 2. 企业内部系统整合 → **SSO + JWT组合** 3. 传统Web应用(同) → Session方案更简单 > 附:前端存储Token的安全方式 > ```javascript > // 避免LocalStorage(防XSS),使用HttpOnly Cookie > document.cookie = `token=${token}; Secure; SameSite=None; HttpOnly`; > ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值