Question about redirect_uri_path

[venkatmarepalli]

This issue is similar to issue #7

Once the Authentication provider redirects the page back. The browser with redirect_uri in this case (/secured) with all the scope, state and code parameters doesn't show anything. I am trying to redirect the user to Home page in this case its http://xyz.abc.com:8888. When I manually modify the url by removing the string starting from secured, it works.

Sometimes the redirection happens correctly to the Home page http://xyz.abc.com:8888 without /secured querystring.

Here is the url that is coming back after authentication
Initial Url:

http://xyz.abc.com:8888

Return Url:

http://xyz.abc.com:8888/secured?code=AQABAAIAAADRNYRQ3dhRSrm-4K-adpCJ7YXOwPP2_C_d2P7-QxX1uqmYzl1YXCS4i8Re3wSlYhmj7HNv-2s0_Y41P20yHNCfYJq6joqiMJ6C-Q3ot524UnRPBfjwFhpOlcr4gAA&state=107364f895c8f787fb28d&session_state=c8b0a1f4-fcee-4c98-9351-dfda1

Here is the conf file

    # authentication
    location ~ (\.cgi$|(^/(logout|secured)$)) {
        set $auth_email "";
        set $auth_realname "";
        access_by_lua '
          local opts = {
             -- the full redirect URI must be protected by this script and becomes:
             -- ngx.var.scheme.."://"..ngx.var.http_host..opts.redirect_uri_path
             -- unless the scheme is overridden using opts.redirect_uri_scheme or an X-Forwarded-Proto header in the incoming request
             redirect_uri_scheme = "http"
             redirect_uri_path = "/secured",
--          Need to make sure discovery path matches the response data
             discovery = "https://login.microsoftonline.com/../.well-known/openid-configuration",
             client_id = "xxxxx",
             client_secret = "xxxxxxxyyyyyy,
             --ssl_verify = "no"
             --authorization_params = { hd="pingidentity.com" },
             --scope = "openid email profile",
             iat_slack = 600,
             --logout_path = "/logout",
             token_endpoint_auth_method ="client_secret_post",
          }

Thanks in advance!

[zandbelt]

Can you paste a browser trace and a server debug log?

[venkatmarepalli]

Browser-Trace.txt
Server-Debug.txt

[zandbelt]

everything seems to be ok: the id_token is retrieved from the token endpoint and the userinfo endpoint returns information just fine; only after that it says:

nginx: lua atpanic: Lua VM crashed, reason: access_by_lua(nginx_psgi.conf:189):57: bad argument #1 to 'authenticate' (string expected, got nil)

assuming that that line 189 says something like:

          local res, err = require("resty.openidc").authenticate(opts)

it looks like a local config error where opts is out of scope

[venkatmarepalli]

Here is the actual tail of the server-debug. That error was due to some typos on that line.

Any pointers on where to start in getting this fixed? I am thinking of Re-redirect if the url has /secured?code..... Do you think this will work?

280b44 HTTP/1.1", host: "xyz.abc.com:8888"
2017/03/22 19:13:53 [] 31744#0: *17 [lua] http.lua:610: send_request():
GET /f34e5979-57d9-4aaa-ad4d-b122a662184d/openid/userinfo HTTP/1.1
Host: login.windows.net
User-Agent: lua-resty-http/0.10 (Lua) ngx_lua/10007
Authorization: Bearer AQABAAAAAADRNYRQ3dhRSrm-4K-adpCJ0drlow4PJhlYmgxwE4t4k-4z0Dtc1D9NWa7NJ_40oU4CL8uhWbqZWGJzwV-1AYQOx6LSr74mBR3qIbjTD2FZgh9qvv3LY7DK7fOvZkWvTqBh9IrUUfJ0_dOirTbUHolbSOqaM4MbUaePDzUHFdYbkludcNiYPykBcZZLc82u2aFwfbR7YPVVthMT2ElTSa4nnGKsROLjkNGbgkdgbTqDOgRi2YAWBmNXqJp80oHH-IdtGI_8tb4pB6o0Er_sZcqaXVoLpx6sZ7nOZgcwOHIx00eBvV3PfDS7uS4bOCyDpL8SbH57zKqvY2La44m0Jei6HSzQs4g3Y3-vDy6iAA

, client: 10.72.26.65, server: xyz.abc.com, request: "GET /secured?code=AQABAAIAAADRNYRQ3dhRSrm-4K-adpCJ7QuBzzbiEN2UYqedv9edinmceYn65KppbInn_ztq7JVeQ3I-Z27Rl14_rHcXY4dG31imNkxaxD-ODQngQlYfX3YDcdNMWrYJH5-P7w4_tC182Gho-Yj16pV5kWkO0WX5B4sclxnufgVcbJmUS3HBz0Bnp05W2X9ONYAcqf5hXxBsOBV63CrsYKIYQg3EvaZciTZgSxXK3FDywr6DlPWh0rjpmNMYkPW7gV6nP8E_NIGVASI_y8ku2fCIrOn9LxQ2cJNd3chMUkUc-QzL262ioJNFTSPsOMSPBeE5aVslU0-DUzBbqc_ubHHOOoU8nL0wnJ83S1rwDqGEPcNb_REIiOi-Lp1Natasu-dAi4v5aSR3NHlakpgeR-J2y7Zp1lJYxC2AoV9g4awrbXFS9aEdAla9OwQS8Bf9LNjA40eg4pw1cIAA&state=98ac4b5bcc48669a43e252aceeac1422&session_state=25c0f8ea-ed2e-4bd3-88da-d0c05c280b44 HTTP/1.1", host: "xyz.abc.com:8888"
2017/03/22 19:13:54 [notice] 31712#0: signal 17 (SIGCHLD) received
2017/03/22 19:13:54 [alert] 31712#0: worker process 31744 exited on signal 11 (core dumped)
2017/03/22 19:13:54 [notice] 31712#0: start worker process 31764

[zandbelt]

it would be interesting to see a full server debug log and check that the request to openid/userinfo successfully returns, which doesn't seem to be the case

[zandbelt]

http://stackoverflow.com/questions/42940166/how-do-i-redirect-back-to-the-home-page-after-authentication/42976054?noredirect=1#comment73109697_42976054 suggests that there may be an issue with session management; @bungle may have some insights on what could cause the "alternating" behavior described in the stackoverflow comment

[bungle]

I cannot help if I cannot see full config / code. Please note that ngx.redirect is one kind of os.exit (e.g. have you remembered to save session data before redirects?). @venkatmarepalli. please try to give a minimal working example where this occurs because otherwise I need to go through a lot of hops.

@zandbelt, one thing I see as a small problem starts here:
https://github.com/pingidentity/lua-resty-openidc/blob/master/lib/resty/openidc.lua#L537

After that the session is passed to some of the functions that seem to return things like:

return nil, err, session.data.original_url

or

return ngx.redirect(session.data.original_url)

But you never check e.g. session presence with session.present, what if there was a problem with attaching the session (aka, there was no session that could be opened, or that there was, but it failed to open it because say HMAC problems, decrypting problems etc.).

[venkatmarepalli]

@bungle I am also suspecting the problem at the same line at session.open . I am just trying to execute a simple application nothing special, but I will try to get you the full config to debug.

[zandbelt]

the commit above may avoid the crash; it does not explain or solve the root problem of the non-existent session

[bungle]

@zandbelt great. For the other question, I think I need more background information. There can be many different reasons:

1. bug in lua-resty-session
2. incorrect usage of lua-resty-session
3. some weird edge case that includes say: multiple browser frames, race-conditions etc.
4. something wrong with the environment where this error occurs

[zandbelt]

my best guess is 4. since that is what I have observed multiple times in the past months; using a minimalized config would typically confirm that the problem is in the configuration/interference with other NINGX configs/routes/functionality; perhaps @venkatmarepalli can give it try with the default minimal config from the README.md

[zandbelt]

@venkatmarepalli did you get a chance to test this?

[venkatmarepalli]

I started off with minimal configuration and slowly added our own configs and everything worked well. I don't see any issues now. Thanks @zandbelt and @bungle for your quick replies.

[BernardCastelein]

I had the same "alternating" behavior problem: when the port 80 is served by the same Nginx, you have to click twice on a url to load a page. When I served those pages in apache on port 80, the Nginx openidc works fine.

Is it a bad idea to serve the reverse proxy authentication and the website in the same Nginx?

My config file :

http {
  server {
    listen 8081;
    location / {
      access_by_lua_block {
          local opts = {
			 redirect_uri_path = "/secure",
             discovery = "https://login.microsoftonline.com/xxxx",	
...			 
          }
          local res, err = require("resty.openidc").authenticate(opts)
          ngx.req.set_header("X-USER", res.id_token.sub)
      }
       proxy_pass http://localhost:80;
    }
  }
  server {
        listen 80;
        location / {
            root html;
        }
  }  
}

[BernardCastelein]

This fixes the alternating behaviour problem: replace the proxy_pass with try_files (for all html files served by Nginx) and proxy_pass to another webserver for the api's
'''
http {
server {
listen 8081;
location / {
access_by_lua_block {
local opts = {
redirect_uri_path = "/secure",
discovery = "https://login.microsoftonline.com/xxxx",
...
}
local res, err = require("resty.openidc").authenticate(opts)
ngx.req.set_header("X-USER", res.id_token.sub)
}
--proxy_pass http://localhost:80;
rewrite ^/api/(.*)$ /$1 last;
try_files $uri $uri.html $uri/ /index.html;
}
location ^~ /api1 {
internal;
proxy_pass http://localhost:80/api/api1;
}

'''
Inspired by
https://www.digitalocean.com/community/tutorials/understanding-nginx-server-and-location-block-selection-algorithms