cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Berto Murillo (JIRA)" <>
Subject [jira] [Commented] (CXF-6572) OAuth2 Hawk Scheme requests
Date Tue, 01 Sep 2015 03:17:46 GMT


Berto Murillo commented on CXF-6572:

1) That is what I mean.  Right now, the CXF OAuth2 HawkAuthorizationScheme code refers to
port in HttpRequestProperties which is fine.  But sometimes HttpRequestProperties utilizes
URI.getPort() which returns -1 if the port isn't explicitly specified which is a Java behavior.
 Instead, if the port isn't specified, it should use 80 for http and 443 for https.  This
would uncouple the server code from Java behavior.

2) Thanks!

3) I can see your reasoning of not wanting to implement and I agree that HTTPS should be used
regardless.  It was really more of a matter of wanting to be safe in rare cases such as SSLv3
and TLS are susceptible to exploits.  Better safe than sorry! ;)

I would have submitted patches had I known that was possible instead of creating all these
tickets.  Do I submit patches via

> OAuth2 Hawk Scheme requests
> ---------------------------
>                 Key: CXF-6572
>                 URL:
>             Project: CXF
>          Issue Type: Improvement
>          Components: JAX-RS Security
>            Reporter: Berto Murillo
>              Labels: oauth2, security
> Hi,
> References:
> Just a few general requests regarding the Hawk scheme.
> 1) It looks like the port being used in the Hawk digest is -1 if the port is unspecified.
 Is it possible to default to 80 for http and 443 for https instead of -1? For clients, I
don't think -1 is a standard behavior outside of Java if a port isn't specified and it can
be confusing.
> 2) It looks like per the Hawk website above, the header's normalization string should
begin with "hawk.1.header".
> 3) It would be great if request payload validation could be added.  It looks like that
is currently a spot where "" is being added in its place.  I want to ensure that the request
itself wasn't modified mid-request if using HTTP and not HTTPS.
> Thanks!

This message was sent by Atlassian JIRA

View raw message