Add secure flag to requests #1823
Conversation
|
play2-PRs #837 FAILURE |
|
I hate it when I break the build. Not sure what the problem is, though. There's this warning about code style, but it's less than enlightening: [warn] Scalariform parser error for /Users/kenji/src/playframework/framework/src/play/src/main/scala/play/core/server/netty/PlayDefaultUpstreamHandler.scala: Expected token SEMI but got Token(CASE,case,13181,case) |
|
play2-PRs #839 FAILURE |
|
play2-PRs #840 FAILURE |
|
@kamatsuoka Please squash the commits and also note that the pr validation is failing - probably scalariform |
|
play2-PRs #847 SUCCESS |
|
@huntc GIt newb question, is squashing the commits something to do for next time, or is it something I can do for this pull request? |
|
@kamatsuoka It's something you can do for this pull request. You can find instructions here on how to squash your commits: http://gitready.com/advanced/2009/02/10/squashing-commits-with-rebase.html Once you've done that, you can push your changes back to the same branch ( |
| * Gets the value of a header, if the remote address is localhost or | ||
| * if the trustxforwarded configuration property is true | ||
| */ | ||
| def forwardedHeader(remoteAddress: String, headerName: String) = for { |
|
Thanks. When I try running git rebase -i HEAD~9, I get 3 or 4 changes made by other people, along with a dire warning about "If you remove a line here THAT COMMIT WILL BE LOST." How to proceed? |
|
Try first ensuring that your master branch is up to date with the latest from this repo, then do a Now it probably shouldn't bring in other peoples commits when you squash. If it does, remove them, they are already on master, they are not needed in your commit. |
|
Argh. When I look at master, I only see two changes from Friday. I tried squashing commits on the add-secure-flag-to-requests branch, but got "error: could not apply 91b1787... Adding a secure flag to requests." Any suggestions? |
|
Okay, I tried the rebase using the oldest commit and it seems to have worked. |
|
... except I committed .gitignore and generated keystore sigh |
|
Okay, extraneous files removed and revisions squashed. |
|
play2-PRs #856 SUCCESS |
|
play2-PRs #857 FAILURE |
This is an updated version of playframework#1326, incorporating suggestions in the comments, and including tests. Play-Cache test was running out of perm gen space
|
play2-PRs #858 FAILURE |
|
Closing/opening to retrigger PR validation - there was a race condition in master that caused it to fail. |
|
play2-PRs #862 SUCCESS |
|
Is there any way to examine the TLS / SSL information on the request in more detail? The reason I ask is because it would be nice to have the equivalent of https://www.howsmyssl.com/ available in Play, but I don't think it would be possible to do it right now. |
|
This would allow it: The difficulty though is that SSL will often be terminated at a reverse proxy, and in fact we recommend that as a best practice, so providing access to the SSL context in that case would be useless. |
That's fine, I would like it just for verifying integration tests. |
|
Fair enough. You could do something roughly like this (no idea about the exact APIs here): val server = new SSLServerSocket(Helpers.testServerPort)
val socketFuture = Future {
server.accept().asInstanceOf[SSLSocket]
}
val result = WS.url(...).get()
val socket = await(socketFuture)
// Run asserts on the sockets SSL session
socket.getOutputStream().write("HTTP/1.1 200 OK\nContent-Length: 0\nConnection: close\n\n")
socket.getInputStream().readBytes(...)
socket.close()
serverSocket.close()The advantage of this is that your WS tests are completely shielded from whatever the Play server does or doesn't support, you've got full power over the SSL connection etc. You might even find that a little bit simpler than having to set up a full Play application to test. |
|
I noticed the JDK test suite uses the same kind of pattern leveraging raw SSLEngine: so I'll check that out. |
Secure schema information is in header X-Forwarded-Proto not X-Scheme
This is an updated version of #1326, incorporating
suggestions in the comments, and including tests.