checking headers

[Larry Martell]

On Tue, May 31, 2016 at 4:19 PM, Francis Daly <francis at daoine.org> wrote:
> On Tue, May 31, 2016 at 12:33:56PM -0400, Larry Martell wrote:
>> On Tue, May 31, 2016 at 11:38 AM, Francis Daly <francis at daoine.org> wrote:
>> > On Tue, May 31, 2016 at 10:26:26AM -0400, Larry Martell wrote:
>
> Hi there,
>
>> >> The C++ app sends the request directly to port 8000. With the django
>> >> app a request is sent to port 8004 and django sends a 301 redirect to
>> >> 8000. In both cases the header field X-Capdata-Auth is set. And in
>> >> neither case does my config pick that up. This is what I have:
>
>> Using curl I can see that ngixn is doing the right thing. Looking at
>> the request coming out of the clients show the header being there.
>> Using tcpdump I do not see the header. I know this is no longer an
>> nginx question, but anyone know why that header would get dropped
>> along the way?
>
> It sounds like your design is that your client sends a http request to
> port 8004; the http service there returns a 301 redirect to a url on port
> 8000 and includes a particular response header; and you want your client
> to follow the redirect by making a new request to port 8000 and include a
> request header that mirrors the particular response header that you sent.

With the django app, what you are saying is correct.

> If you are using the client that you wrote, then you can make sure that
> it does that.
>
> If you are using a general http client, it is unlikely to do that.

I am knida new to all this. The apps were written by someone who quit
and then this was all dropped in my lap. I thought I was clear on what
a client and server were in life, in this app it's somewhat screwy.
What is behind port 8000 is nginx routing to some Angular code that
sends a request out. So the Angular code, although client side, is
acting like a server in that it is invoked in response to a request.
Then it turns about and acts like a client and sends a request out.
So, who's the server here? nginx?

There are 2 approved ways to send a request to port 8000. One is from
an app we wrote that is in C++ and it directly sends the request to
port 8000. These requests are always previously authenticated and are
good to go. The second is from a django endpoint listening on 8004. It
does some authentication and if all is good, redirects to 8000. So
with both of these cases I want to request to port 8000 to go through.

Then, of course, there are myriad other ways for a request to get port
8000 - from a browser, curl, wget, etc. In all of these cases I want
the request to be blocked and return a 401.

I was hoping to do this with a custom header, but that appears not to
work. Can anyone recommend another way to achieve this?

> Perhaps an alternate design involving reverse-proxying would be valid?

How would that help me?

Thanks!