HTTP header 'Authorization: XXXXXXXX' is not allowed in responses

[Isammoc]

Play Version 2.6.0

I am migrating from 2.5.3

API Scala

Operating System (Ubuntu 15.10 / MacOS 10.10 / Windows 10)

Linux desktop 4.10.0-26-generic #30-Ubuntu SMP Tue Jun 27 09:30:12 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

JDK (Oracle 1.8.0_72, OpenJDK 1.8.x, Azul Zing)

java version "1.8.0_111"
Java(TM) SE Runtime Environment (build 1.8.0_111-b14)
Java HotSpot(TM) 64-Bit Server VM (build 25.111-b14, mixed mode)

Library Dependencies

I try to migrate my application based on jwt-play.

Expected Behavior

Please describe the expected behavior of the issue, starting from the first action.

1. When the header 'Authorization' is added with Result.withHeaders
2. The response should include an header 'Authorization' with the filled value

Actual Behavior

No error, only a log :

[WARN] [07/02/2017 12:25:17.568] [play-dev-mode-akka.actor.default-dispatcher-9] [akka.actor.ActorSystemImpl(play-dev-mode)] HTTP header 'Authorization: XXXXXX' is not allowed in responses

The response is served (200 OK, or other), but the header is not here.

Reproducible Test Case

1. From g8 play-scala-starter
2. add .withHeaders("Authorization" -> "Bearer 1234") at the end of line 22 in HomeController.scala (add headers to the Ok result)
3. Launch application
4. Go to http://localhost:9000
5. The page is rendered
6. The Authorization header is not rendered
7. A similar log exists

[Isammoc]

Note: I tried to workaround with the illegal-response-header-value-processing-mode = ignore configuration, but no place seems to be the good one. ( play.server, play.server.akka, play.akka.dev-mode etc.)

[marcospereira]

The correct configuration key is akka.http.parsing.illegal-response-header-value-processing-mode. See more here:

http://doc.akka.io/docs/akka-http/current/scala/http/configuration.html

I'm not sure that changing it will solve this problem, But it shouldn't be necessary to manually configure it to standard headers anyway.

[schmitch]

well basically this is not a defect, since Authorization is basically a incorrect response header. However since play 2.5 and below never enforced it, I think the parsing error is unsuitable.

[Isammoc]

@marcospereira I tried with following lines in my conf/application.conf:

# mentioned value
akka.http.parsing.illegal-response-header-value-processing-mode = ignore
# prefix 'play.server.akka': https://playframework.com/documentation/2.6.x/SettingsAkkaHttp
play.server.akka.http.parsing.illegal-response-header-value-processing-mode = ignore

# Other tests
play.akka.http.parsing.illegal-response-header-value-processing-mode = ignore
play.server.akka.http.parsing.illegal-response-header-value-processing-mode = ignore
play.server.http.parsing.illegal-response-header-value-processing-mode = ignore

Even with all this values, my Authorization header is not rendered :'(

@schmitch Why this particular header is incorrect in a response header?

Basically, what I try to do is to manage credentials information with refreshing data (JWT token with expiration date).

For each request with a valid Authorization token, my server answers with a refreshed token in the same named header. (alongside the usual answer to the request, of course).

I should be blind (or don't know which request to send to google 👅 ) , but I didn't find anything about that particular header unsuitable to the response part.

I agree with your second part about the parsing error is unsuitable since play 2.5 never enforced it.
But with all the others modifications (ActionBuilder, Controller, etc.) I won't enforce the fact this version is major 👅 But a mean to reach the same API as before could be loveable.

[schmitch]

you need to use devSettings

Example:

PlayKeys.devSettings := Seq("akka.http.parsing.illegal-response-header-value-processing-mode" -> "ignore")

inside your build.sbt.

The header is incorrect since it's a client only header. for your use case it's better to create a "custom" header, i.e. Set-Authorization or Set-Token which is not a http specified header.
Authorization is a "special" (headers inside the specification mostly have a way on how they are handled, i.e. Set-Cookie, Cookie, etc.) header that should only be set on client side code.

[Isammoc]

Two more tests:

1. I copied your line into my build.sbt and I launched with ./sbt ~run (as usual with the sbt wrapper)
2. I launched my application with ./sbt -Dakka.http.parsing.illegal-response-header-value-processing-mode=ignore ~run

Both cases: the Authorization header is not rendered. Same log.

The RFC defines the use of this header as to contain the credentials of the client. And show an example with the request. But in my case, it's really the credentials of the client, refreshed by the server.

[marcospereira]

The problem here is that, while Authorization is a standard header, it is a request header that the user agent should send. From the RFC:

The "Authorization" header field allows a user agent to authenticate itself with an origin server -- usually, but not necessarily, after receiving a 401 (Unauthorized) response. Its value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested.

Authorization = credentials

If a request is authenticated and a realm specified, the same credentials are presumed to be valid for all other requests within this realm (assuming that the authentication scheme itself does not require otherwise, such as credentials that vary according to a challenge value or using synchronized clocks).

So, while it is not illegal to have an Authorization on responses, it is also not standard. Maybe it would be better to use a custom header (My-Authorization, for example) which won't overlap with Authorization.

@Isammoc could you please explain better why do you need to send Authorization as a response header?

[Isammoc]

@marcospereira As the Authorization header is only defined in request. When used in response it is a custom header. I don't see the problem.

Currently, I need to have same name for header in request and response. (the current version of the jwt-play plugin does not allow me to configure different name for request and response. As my JWT is about credentials of the client, I want to use Authorization header in request.

I will ask to the jwt-play plugin for the feature to have separate configuration for request and response header name. But Authorization should not be illegal in response, only treated as a custom header.

[marcospereira]

Agree that it should be treated as a custom header. No problem with that.

[richdougherty]

Hi @Isammoc, this issue is now addressed in Play 2.6.1 if you want to try it out.

[Isammoc]

Tested and approved 🎆

Thanks for the work! ^^

Keep going to do as good a work!

Cheers