d the request.
Is that what you are looking for?
Johannes
On Saturday, May 20, 2017 at 12:47:03 AM UTC+2, Andrew Norman wrote:
This would be for a system that services requests from users directly and also
with other systems. Users would have a session cookie and non-user systems a
toke
This would be for a system that services requests from users directly and
also with other systems. Users would have a session cookie and non-user
systems a token.
The idea / paradigm here is the old java interceptor authentication
approach where authentication was attempted a number of ways
is this not a common environment setup? (aka. an application.conf inside an
uber jar containing application configurations and an external smaller conf
file that contains a small set of environment-specific overrides)
if it isn't I'd be happy to here how others manage application
We've both gotten ssl to work in a manual (aka non-sslConfig) way. My
question still stands though. Has the sslConfig actually been wired to work
with akka-http or is this still something being worked on? If the former is
there any example to a config-based ssl integration?
And please don't
I have a file named restapi.conf that lives in a remote location outside
the jar. It has the following content:
include "application"
akka {
loglevel = "DEBUG"
}
my application.conf file referenced by the remote file lives inside the jar
of my akka-http application.
it has the
The information for setting up akka-http ssl is very cluttered / inaccurate
/ dated / and referencing mismatched links from other systems (such as Play
WS ssl client configurations) which doesn't really tell you how to
implement server-side ssl. Every code example I see out there on how to
