Use `$_SERVER` rather than `getenv()` for server request vars about automad

[michaellenaghan]

There are 23 uses of getenv() in 6 files. I checked them against the keys listed on the $_SERVER page; it looks like all of them should be switched to $_SERVER. (Btw, a couple of keys, like SERVER_NAME, are currently accessed both ways.)

Let me know if you'd like me to tackle this.

(Btw, just for completeness, my original list missed one key: SERVER_PORT.)

[marcantondahmen]

Hi, thanks for reporting this. The advantage of getenv is that it doesn't require a check whether a key exists. In that sense one could argue it is even the better solution. But I understand your trouble and will take a look at it.

However, there is an easy way to make the index.php disappear from the URL. In case the automatic detection fails, you can set the AM_INDEX constant to an empty string in the config.

[michaellenaghan]

In that sense one could argue it is even the better solution. But I understand your trouble and will take a look at it.

Marc, this isn't "my trouble." It's about the wrong approach and the right approach. There's no sense in which one could argue that the wrong approach is the better solution!

I sent you a thread in which the Symfony developers admitted they were wrong, and changed their code. (There's a lot of detail in that thread. It's worth a careful read. I followed links and looked at the source code they were talking about.)

After finding that, I took the time to verify that both Laravel and Symfony exclusively use $_SERVER for server request vars today.

Here is Grav, another flat-file PHP-based CMS. Same thing.

Here is Kirby, another flat-file PHP-based CMS. Same thing.

If you like the convenience of what getenv() provides you can create a small wrapper around $_SERVER that works the same way.

[poetaster]

_SERVER is the correct solution. As it currently is, automad cannot be run behind distributed transparent caching proxies. Which is a bit sad, since it's quite nice.

I haven't tested if the putenv solution above will work with ha-proxy / varnish & a cdn, but I'll try to get to it.

[poetaster]

I haven't tested if the putenv solution above will work with ha-proxy / varnish & a cdn, but I'll try to get to it.

No, that is not sufficient. I'm not sure what is happening here, but I can varnishlog the POST requests. I checked to make sure that no form / session cookies are being unset (are not), but login does not work. It does with the same setup on a drupal install.

[marcantondahmen]

Hi, so it looks that switching to $_SERVER would be the only working solution, right? I haven't tested it in the environment you described though. But I guess it is not a big deal to replace getenv() entirely.

It will probably be fixed in the next major release.

[marcantondahmen]

One other thing came into my mind. There is the AM_BASE_PROXY constant that can be defined in the config in order to address issues with URL rewriting for pages behind proxies. Maybe you could give that one a quick try.

[poetaster]

One other thing came into my mind. There is the AM_BASE_PROXY constant that can be defined in the config in order to address issues with URL rewriting for pages behind proxies. Maybe you could give that one a quick try.

I'll try this later this evening. Thanks!

[poetaster]

One other thing came into my mind. There is the AM_BASE_PROXY constant that can be defined in the config in order to address issues with URL rewriting for pages behind proxies. Maybe you could give that one a quick try.

Errr, what should it be set to? In my drupal configs I noted 127.0.0.1 ?

[poetaster]

127.0.0.1 ? that value does not work ;)

[marcantondahmen]

After taking a closer look, it turned out that it needed more than changing from getenv() to $_SERVER. That actually has really nothing todo with it at all, as I mentioned before. However, I agree that a streamlined use of $_SERVER is more consistent here as well.

The actual issue is that the automatic determination of the base URL is not working correctly when running behind a proxy. That basically breaks the app. In the beginning it was not meant to run in such a scenario and also was not really tested therefore.

However, I have just added the ability to run behind a proxy. The feature will be included in the next major release.

[poetaster]

However, I have just added the ability to run behind a proxy. The feature will be included in the next major release.

Ah, that's great news. I host a lot of smaller sites on IPv6 only virts and proxy IPv4 with a transparent cache, so that would make those scenarios automadic :) Thanks for all your work!