-- Configure DNS
-- Downloads docker image and manifest file from the Cloudron app store
-- Sets up addons
-- Logrotate, Collect (stats about the app, how much CPU, memory it using etc), Firewall
-- Runs the docker container
--- Dynamic configuration (giving the app db credentials, SMTP credentials to send email, e.g. for WordPress it creates the wp-config.php file with all the relevant credentials)
-- Gets SSL certificates from LetsEncrypt (and set-up reverse proxy, i.e. when blog.domain.com is visited forward to this container)
-- Read only and stateless app containers (all apps are read only - apps cannot write to their file system, if they could then users could add all sorts of random files and it wouldn't be possible to update smoothly, the code cannot be modified. This means when there is an update we can just throw away the old container and get in the new container. So where does the app write stuff it needs to? We let the app write in 3 locations 1) /tmp for temporary files 2) /run which contains runtime files which an app needs to communication across various processes, 3) app/data/ where the app will put images, files uploaded etc - everything in app data is part of the backup, /tmp and /run is not backed up)
-- Rolling updates
-- Signed releases
-- Selenium based tests (test that everything actually still works)
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:
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.
@saikarthik Yes, the proxy addon seems good for what you are looking for.
However, it's not available yet, it'll only be released with Cloudron 6 (I think the devs estimated about 2 weeks, but it's only an estimate).
Also, it does not allow for more fine-grained control, so if you want to restrict only a few things, you'll have to do it manually, and in that case yeah you can take inspiration in the Surfer app for example.
and about workflows based on incoming mails i don't know if there is ready to use plugins but i will do that for my own dolibarr (a special pop/imap account for dolibarr and some actions on incoming mails, all of that is based on dolibarr API and calls from command line)
@saikarthik Looks like it's a PHP script - if you are keen to get this tested on Cloudron right now, just install the LAMP app and upload the script and install as normal. Looking at the requirements, the LAMP app should be able to handle this no problem (for testing)
@saikarthik If it's a paid-only app, then Confluence already in the App store is already a precedent for that model. I could do with an instance of JIRA too, reluctantly as I never liked their licensing model, but could do with it for archiving purposes.