Reverse proxy and https

[patrixl]

Hi,

Hopefully can get more info/assistance or provide more data to help fix this.

I’ve been using Radiance recently and it’s been perfect for my needs. I’m now setting it up with nginx as reverse proxy and for ssl termination, however I’m running into some issues. I hope some people here can help point me in the right direction.

So because I’ll be using ssl, in my configuration I’ve set (mconfig :radiance :port) to 443, which correctly sets the protocol to https when for example I use (uri-to-url).

To be precise, radiance is configured port 443 but i-hunchentoot is listening on port 9090 (no ssl), and nginx is listening on port 443.

And again due to radiance being set to port 443, radiance’s own functions properly recognize that it should use https as protocol when generating urls.

(Note that after Shinmera's suggestion of adding a reversal route to force port 443, this setting being 443 or 9090 does not affect the URLs created with (uri-to-url).

However when using r-clip to parse my ctml templates, and using the @action or @src or @href attributes, these will default to plain http. This breaks my site since js, css, etc won’t be loaded by modern browsers now due to being less secure.

Am I missing something, or is there a known workaround, or is this yet unfixed? I can provide code snippets if necessary and configuration examples, in case the above isn’t clear enough.

As suggested by Shinmera, I've tried to add this reversal route:

(define-route force-port :reversal (uri)
  (setf (port uri) 443))

It works well for anything related to pages and static routes.

As soon as I try an API request though, even one that has no :access option, it redirects me to a /login page, which never happened before. Does this new route somehow interfere with the API?

Thanks again Patrix.

[Shinmera]

No, the route should not have anything to do with the API -- I use the same route in production fwiw. What are your API definitions and how are you calling them?

[patrixl]

Sorry, nevermind that part about the API routes being messed up - it was a leftover nginx configuration that shouldn't have been there.

Let me test some more with that reversal route and get back to you.

Thanks. Patrix.

[patrixl]

Alright, everything's good for now, thanks for the help.

FWIW, Nginx does send the X-Forwarded-Proto header, which is set to https in my case.

Thanks.

[Shinmera]

Okey, with 59c1993, uri-to-url should automatically consider the X-Forwarded-Proto header value. If you can (ql:update-dist "shirakumo") and re-test without the port forcing that would be great.

[patrixl]

Hey that did it! Thanks for the quick turnaround. Same app is now reachable both over https through nginx, and over plain http on its backend port (although that's just me debugging, it shouldn't be accessible over plain http)

[Shinmera]

Great :)