Cloudron makes it easy to run web apps like WordPress, Nextcloud, GitLab on your server. Find out more or install now.


Skip to content
  • 1 Votes
    4 Posts
    91 Views
    girishG

    I tried with a VPN and it picks up different locations correctly.

    image.png

  • 1 Votes
    12 Posts
    678 Views
    Sam_ukS

    I'd like to use https://www.npmjs.com/package/@digital-boss/n8n-nodes-humhub in my N8N instance, so ability to install packages would be great.

  • Cloudron CLI & 2FA

    Solved Support
    8
    0 Votes
    8 Posts
    419 Views
    girishG

    I have pushed a new CLI version v4.12.7 that fixes this.

  • 0 Votes
    6 Posts
    425 Views
    M

    @girish Boom! Back up and running 🙂
    Well this was a joyous outcome. Thanks a bunch Girish!

  • 0 Votes
    3 Posts
    632 Views
    jimcavoliJ

    Note: It took me a minute to put this together while @nebulon was responding and I got pulled onto something else for a minute, but I think the detailed writeup is worth having for posterity, so I'll post it anyway.

    So what's going on here is that the app in question isn't reading the "right" headers to find the remote address. Basically, the inbound requests come in and hit the box-level nginx reverse proxy, which forwards the request on with the original inbound IP in the X-Forwarded-For header. Since from the sound of it, you're just routing straight to your app in the container, you'll want to either reconfigure your logging library to use the forwarded IP header as the client IP or drop nginx or similar as a reverse proxy in front of your app and configure it to rearrange the incoming headers as your app needs.

    Sounds like you can just adjust a configuration so that this (your existing flow) works nicely:
    container-sans-rp.png
    Basically, here, the headers are adjusted in the "Step 1" processing as they reach the Cloudron so when they reach your app, the proxied headers have already gone into place. Again, this configuration should be fine with the configuration that @nebulon mentioned going in, since that should reconfigure your framework to read these adjusted headers correctly.

    Failing that, or for apps with more complex setup or which aren't able to read those headers on their own by configuration, the solution is to further proxy those requests, by adding nginx or similar to take over the "Step 3" handoff and smooth out any specific details (like re-adjusting headers) for the app, and having it proxy those requests down to your app, all in-container, so that the logging and such in your app will all match up with expectations/reality. The whole point of the second reverse proxy when it's added it to make the world appear as it needs to for the app and/or its components inside the container.
    container-rp.png

  • NodeJS Server

    Moved Solved Support
    5
    1 Votes
    5 Posts
    856 Views
    girishG

    For others looking for examples, there's a bunch of custom app templates I made that should help getting started:

    https://git.cloudron.io/cloudron/tutorial-php-app/ https://git.cloudron.io/cloudron/tutorial-nodejs-app https://git.cloudron.io/cloudron/tutorial-basic https://git.cloudron.io/cloudron/tutorial-redis https://git.cloudron.io/cloudron/tutorial-supervisor-app