当前位置:   article > 正文

Jersey Client基于Https的Basic Authorization_jersey basic auth

jersey basic auth

当我们使用Jersey客户端进行Https请求的时候,需要一些Basic的认证,例如我们在请求Github开放平台的时候,只有在请求头中带用户名和密码的基本认证,才会返回结果,那么Jersey客户端如何进行Basic的认证了?(Jersey的代理问题一直没有解决,如果有知道的大牛,还请告知,Thanks!)

方式一:基本认证

  1. HttpAuthenticationFeature feature = HttpAuthenticationFeature.basic("username", "password");// 基本认证的Feature
  2. Response response = client.target("https://api.github.com/search/code?q=chhliu+language:java")
  3. .register(feature)// 将Feature注册到Jersey Client中
  4. .request().get();
  5. System.out.println(response.readEntity(String.class));
方式二:不使用任何默认证书的认证,但是这种认证需要在每次请求中提供用户名和密码以请求属性的方式

  1. HttpAuthenticationFeature feature = HttpAuthenticationFeature.basicBuilder().build();// 首先build一个空的Feature
  2. Response response = client.target("https://api.github.com/search/code?q=chhliu+language:java")
  3. .register(feature).request()
  4. .property(HttpAuthenticationFeature.HTTP_AUTHENTICATION_BASIC_USERNAME, "username")// 指定Feature的用户名
  5. .property(HttpAuthenticationFeature.HTTP_AUTHENTICATION_BASIC_PASSWORD, "password").get();// 指定Feature对应的密码
  6. System.out.println(response.readEntity(String.class));
方式三:非preemptive模式的认证

  1. HttpAuthenticationFeature feature = HttpAuthenticationFeature.basicBuilder()
  2. .nonPreemptive().credentials("username", "password").build();
  3. Response response = client.target("https://api.github.com/search/code?q=chhliu+language:java")
  4. .register(feature).request().get();
  5. System.out.println(response.readEntity(String.class));// 这种方式允许你重复使用相同的客户端以各种不同的凭证进行身份验证

通过上面的几个步骤,就基本完成了Basic Authorization了。

在Jersey 2.5之前的版本中,支持由org.glassfish.jersey.client.filter.HttpBasicAuthFilter和org.glassfish.jersey.client.filter.HttpDigestAuthFilter提供认证。 自从Jersey 2.5这些过滤器被弃用(并在2.6中删除),并且两个身份验证方法由单个HttpAuthenticationFeature来提供。

为了在Jersey客户端中启用http认证支持,请注册HttpAuthenticationFeature。 此功能可以提供两种身份验证方法,摘要和基本。 功能可以在以下模式下工作

        BASIC:基本preemptive认证。 在preemptive模式下,身份验证信息始终与每个HTTP请求一起发送。 此模式比以下非preemptive模式更常见(如果您需要BASIC认证,则可能使用此preemptive模式)。 此模式必须与SSL / TLS的使用组合,因为密码仅以BASE64编码的方式发送

        基本非preemptive模式:基本非preemptive式认证。 在非preemptive模式下,仅当服务器拒绝带有401状态码的请求时才添加认证信息,然后使用认证信息重复该请求。 这种模式对性能有负面影响。 优点是不需要凭证时,无需发送。 此模式必须与SSL / TLS的使用组合,因为密码仅以BASE64编码的方式发送。

        DIGEST:Http摘要认证。 不需要使用SSL / TLS

        UNIVERSAL:基本认证和摘要认证的组合。 该特性以非preemptive模式工作,这意味着它发送没有认证信息的请求。 如果返回401状态码,则重复该请求,并且基于在响应中请求的认证(在WWW-认证HTTP报头中定义)使用适当的认证。该特征记住哪些认证请求对于给定URI成功,并且下一次尝试 使用最新成功的身份验证方法对此URI进行preemptive式身份验证

声明:本文内容由网友自发贡献,不代表【wpsshop博客】立场,版权归原作者所有,本站不承担相应法律责任。如您发现有侵权的内容,请联系我们。转载请注明出处:https://www.wpsshop.cn/w/AllinToyou/article/detail/124311
推荐阅读
  

闽ICP备14008679号