2

I am trying to intercept the basic popup with nginx and stuck at the user password.

I have a landing page where users would insert a username/password and the form gets posted to http://localhost/validate.

The following is the block that I got, If I hardcode the base64 encoded username:password, things are working but to do it in a programaticaly its not working.

location /validate/ { set_form_input $username; set_form_input $password; set $auth_raw "$username:$password"; set_encode_base64 $digest $auth_raw; # $digest = some_hash_value proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header Authorization "Basic <<<some_hash_value>>>"; # This works #proxy_set_header Authorization "Basic $digest"; # This does not work proxy_pass http://localhost:5601/; } 

As shown above,

Hardcoding the hash value allows me to bypass the basic authentication popup:

proxy_set_header Authorization "Basic <<<some_hash_value>>>"; 

But assigning it using a variable does not work:

proxy_set_header Authorization "Basic $digest"; 

Just by the looks of it, I am unable to dynamically assign the required values for proxy_set_header Authorization.

In short I want to be able to do the following,

  1. User enters username & password on a page & hit submit.
  2. Data get's posted to http://localhost/validate
  3. Nginx sees the request on /validate and start to process the form values and compose the URL (base64 encoded equivalent) http : //username:password@localhost:5601
  4. Server listing on port 5601 sees the username/password and authenticates the user and let the user in.

What am I doing wrong here? Or is there a better way to handle this with nginx?

2
  • @Michael Hampton, a tcpdump shows that the header values are infact different. Commented Jul 13, 2015 at 14:08
  • Please accept your own answer if it resolved the problem. I've submitted a claryfing edit to your answer, hope it is accurate. Commented Feb 20, 2021 at 19:43

1 Answer 1

2

The form submission URL (action attribute) is missing the trailing slash.

Upon form submission POST request is made to /validate which causes nginx to respond with a redirect to /validate/. The browser foIlows the redirect by issuing a GET request which does not contain the original data. Effectively the nginx rules receive empty credentials.

The solution is to add trailing slash to the <form> element's action attribute so it looks like: action="http://localhost/validate/".

4
  • 1
    I completed understood your issue in the original question as I am having the same issue, but I do not understand the resolution. Could you explain it in more detail? Commented Aug 23, 2018 at 11:43
  • 1
    @pholcroft I think The issue was wrong for submission URL. It was missing trailing slash which caused a redirect to the final URL in effect losing the POST data in the process. Commented Feb 20, 2021 at 19:27
  • I did not notice it was bump from past by Community bot. Now it seems I'm an archeologist. Still the qa is worth keeping and improving since it's basic knowledge that's still relevant plus the use case is quite nice. Commented Feb 20, 2021 at 19:49
  • Thanks, I understand the solution now. Next I just need to remember what I was trying to do nearly 3 years ago. Commented Feb 21, 2021 at 20:41

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.