hurrytospring

1. 对，但是需要理解安全机制防的是什么，cors 机制中，防范的是跨站脚本攻击，比如在 A 网站中，发起一个对你服务（ B ）的请求，这个时候就可以携带上 B 的 cookie ，然后在请求中读 B 身份的内容。
至于你说的场景
1.1. 是黑客劫持了响应，然后注入恶意脚本，其实这个时候没有那么麻烦，黑客可以直接劫持 A 的请求。
1.2. 这个场景一般来说是依赖 https 或者更底层的协议来保护，跟 cors 没有关系
2. 身份是一个统一的认证头，key 为 authorization ，如果你就是不用这个 key ，自己设计一个，你就自己越过了这个安全机制，你的服务你自己负责。
2.1 allow:*本质上是一种宽松校验机制，就是如果你认为你这个接口信息不重要，可以让别的站随便拿，你可以定义为*。但是当有这个 header 时，浏览器认为，这不是一个宽松的接口，是含有认证信息的敏感接口，应该采用更严格的校验机制，所以不让你用宽松的配置。
2.2 当然，你可以觉得浏览器说得不对，你换一个认证的 header key ，这个时候浏览器也不对这个事情负责，你可以继续 allow:* ,属于你自己越过安全机制，自己负责

@peitop web 已经有人选了，我们会先跑个 mvp 看看要不要加人，可以保持联系

补充在帖子后面了，base 北京，惠新西街南口附近

线上服务有比较好的吗

@zzz22333
硬件也有需求，但是不是我在负责，可以发个简历我让硬件产品经理看看

我们做硬件，想用 chromeos ，又担心国内招不到这方面的人

@raycake

邮箱 [email protected]