当前位置: 首页 > 知识库问答 >
问题:

使用服务JAX-RS的Angular 2中的授权头

巫马昆杰
2023-03-14
const headers = {
  'Content-Type': 'application/json',
  'Authorization': this.auth.token
};

return this.http.get(this.url, { headers: headers, withCredentials: true })
  .toPromise()
  .then(this.extractData)
  .catch(this.handleErrorPromise);
String authorizationHeader = requestContext.getHeaderString(HttpHeaders.AUTHORIZATION);
    Autenticador autenticacao = new Autenticador();
    String token;

    extrairHeader(requestContext);

    if (authorizationHeader != null && authorizationHeader.contains("Bearer ")) {
        token = authorizationHeader.substring("Bearer ".length()).trim();
        Key key = new KeyGenerator().generateKey();

        return autenticacao.tokenValido(token, key);
    } else {
        return false;
    }

共有1个答案

章睿
2023-03-14

这不是真正的请求,这是CORS的预飞行。由于请求中包含以下标头,您可以知道:

  • 起源
  • 访问-控制-请求-方法
  • Access-Control-Request-Headers

这些头询问服务器是否允许该请求。服务器应该相应地使用响应头进行响应,以告诉浏览器请求是允许的。如果预飞行是可以的,那么真正的请求是提出的。

 类似资料:
  • 你好,我曾与JAX-WS合作开发基于SOAP的网络服务。现在我想使用REST,因为正如我从这里学习的那样,REST比SOAP有优势。 但从不同的文章中,我知道我们也可以从JAX-WS创建RESTful Web服务。但是大多数人说我们应该使用JAX-RS而不是JAX-WS。 我的问题是JAX-WS RESTful webservice和JAX-RS(泽西)之间有什么区别。JAX-RS相对于JAX-W

  • 问题内容: 我有一个JAX- RS服务,我希望所有用户都可以访问我的服务,但只有那些有权查看结果的用户才能访问我的服务。基于角色的安全性以及现有的REALMS和不良处理方法不符合我的要求。 例如: 用户针对一项REST服务进行身份验证,我向他发送了带有其ID的JWT令牌 用户请求其他资源,并在每个请求中发送带有ID的JWT 我检查了他的用户ID(来自JWT),如果业务逻辑返回了结果,我将其发回,否

  • 我目前正在学习一些 Angular2 的教程。不幸的是,我的教程没有涵盖Spotify API现在需要授权。我已经在Spotify开发角设置了一个应用程序。我的 Angular2-服务的代码如下所示 我组件中的构造函数是这样的 现在我的问题是,当我的应用程序运行时,我收到了一个与交叉起源策略有关的错误,这让我有点困惑,我真的不知道在哪里正确设置标头。 XMLHttpRequest无法加载https

  • 我尝试构建一个带有Rest服务和EJB注入的Java EE7应用程序。我创建了一个多模块maven项目,并将其部署在Glassfish 4上。我最后一个EAR包含一个带有EJB的JAR,例如,带有我的Rest服务定义: 当我部署我的应用程序时,我看到下面的日志似乎还可以。即使我想知道它为什么定义“java:global”JNDI,因为默认情况下@Stateless EJB是@local: 编辑1:

  • 泽西-客户端 泽西-普通 jersey-container-servlet jersey-container-servlet-core 泽西-服务器 如果我这样做,我总是得到以下异常: 经过一些研究,我发现我应该添加jersey-servlet-1.12.jar,而不是从上面发布的下载源添加jar。所以我做了。我将其添加到web.xml中

  • 我有一个多租户项目,它将调用多个微服务来执行特定任务。 我希望微服务从发送的请求中了解要使用哪个DB,因为每个租户都将使用微服务,但是,租户将拥有自己的DB。我有另一个解决方案,它有一个处理API密钥管理的Web项目。 比方说,API密钥管理位于域:portal.example.com 当 tenant.example.com 在 microservice.example.com 调用微服务时,我