Revolution: MODX3 Core Folder Name cannot be renamed

[sonicpunk]

Bug report

Summary

When hardening MODX, we always rename our core folder. It seems that when you rename the core folder to something else, autoloading does not work because the 'core' folder name is placed as a static link in /vendor/composer/autoload_psr4.php and /vendor/composer/autoload_static.php

Step to reproduce

You can reproduce this when upgrading a hardened MODX instance that has a renamed core folder from 2.x to 3.x. The core folder in this case is also OUTSIDE of the webroot.

Observed behavior

It gets noticed when going through the MODX setup process. It cannot find the database. xPDO can't connect.

Expected behavior

The setup should be able to readout the name of the core folder from the MODX config and adjust accordingly.

[sonicpunk]

@JoshuaLuckers Hey check out this issue!

[sonicpunk]

This may also be related...

After changing my core folder back to core, I was able to go through the installation process, but now it seems that still something is not correct.:

(ERROR @ /var/www/html/core/src/Revolution/Sources/modFileMediaSource.php : 30) Konnte die Medienquelle "MODX Components" nicht initialisieren! Impossible to create the root directory "". mkdir(): Invalid path

Could it be that we no longer are able to set the core outside of webroot?

[opengeek]

It is currently not possible to move the core directory in 3.x. Composer has to have the path to it for proper autoloading and this cannot be a variable path.

[Mark-H]

Are you using an absolute basePath in that media source @sonicpunk or something like ../foobar?

[sonicpunk]

Is there not a way to add or rewrite the paths to the core folder during the setup? @opengeek

[opengeek]

No, there is not. Composer has to have the path before setup is executed.

[opengeek]

Protecting the core using .htaccess or a simple nginx rule is just as secure as the security-by-obscurity of moving the core.

[sonicpunk]

@Mark-H Yes, Mark to answer your question.. we have media sources that use absolute basepaths.

[wuuti]

I am _not_ satifsfied with the way this issue is handled here from a communication point of view. While "not satisfied" is more an euphemism. In fact it upsets me inexpressibly and strongly reminds me why people reduced their participation in the project and community a lot over the last years - because its always the same.

• closing an issue without any further discussion is a no go. It would be fine to say something like "i disagree because of..., and therefore consider this issue as closable", and if others support that, it _may_ be closed.

• what exactly is the message here? Hey, fine people, we recommended over years to harden your installs (and still do, see the link!), esp. the core to gain more security, and now we simply say "ha, you are fucked, because you chose the secure way and cannot update to the new version now"???

• is it really true that its not possible to have a renamed/core? Ben already depicted that simply changing those two lines may be enough (to be determined of course). So possible solutions imho may be

  • at least document exactly those changes and that this needs to be done manually when updating to 3.x (and possibly every time again you do a 3.x update) _plus_ the hint that hardening like this is not considered to be needed any more (is that so??)
  • have the setup at the checks before exactly check that, and tell the user then directly "hey, your installation was hardened, and setup cannot continue. please do XY and then run setup again"
  • _or/and_ implement a tiny change in the setup, which offers to automatically change core/src to the configured MODX_CORE_PATH/src wherever needed prior to the stages in the setup where the autoloading is used

[opengeek]

This was already discussed extensively in multiple places. If everyone would participate beyond this two-day rush to do everything all at once, there wouldn't be a problem here. It is not possible currently without creating larger problems. This is because there is no way in composer to provide a variable path for autoloading. Just because the issue is closed does not mean there cannot be more discussion about it. If I lock it, then you can get upset.

[JoshuaLuckers]

If changing the references to core/src in the two files mentioned by @sonicpunk, wouldn't it be a good temporary solution to have this in the docs as workaround?

[zaigham]

From where I see it, it is more of a Composer issue than a MODX issue. We could find workarounds, but that would potentially break things elsewhere.

The recommendation to harden the MODX 2.x is from the past when Composer didn't even exist.

[Mark-H]

It comes from the composer.json so that's not configurable per project. Editing generated autoload files is also not something to encourage.

I don't think anyone would object to figuring out how to bring back the ability to move the core. As this is also likely to come up more over the coming weeks and months, I'm going to reopen the issue (for now, at least) to make sure people have a place to discuss ideas on how this might be possible again in the future.

This is also definitely something that should be more clearly stated in the upgrade docs. I thought it was already there but don't see it right now, so have logged an issue to make sure that gets added in the right places. If workarounds become available, that would also be good place to put those.

[wuuti]

The recommendation to harden the MODX 2.x is from the past when Composer didn't even exist.

Then this part of hardening docs should also be changed for the 3.x version, probably totally removed, because its incompatible with the version then.

[wuuti]

I would really appreciate a solution which mitigates that issue when doing the jump from 2.x to 3.x, automatically would be the best way. I can think of a script, maybe run by the setup preparation, which automatically does "undo" the core hardening, or at least enlist the already known steps to make an installation compatible with 3.x. I don't think it is a final (just one part) solution to have the docs updated. As mark said, once 3 is released, we can expect maaany people having issues during the setup and reporting them here or in slack. If our _magic setup wand_ can mitigate already known issues they might have, or at least reduce the number of people gaining support by the community, we should take the chance. There will be enough currently unknown issues for sure we then need to concentrate on.

[rthrash]

There could certainly be a check in the setup that looks for the core directory in its default location and warns about that. Definitely agree on the docs for 3.0, too @wuuti … I can take a stab at the docs including default NGINX web rules and htaccess suggestions to make those inaccessible from the web.

[opengeek]

There could certainly be a check in the setup that looks for the core directory in its default location and warns about that.

Unfortunately, I don't think that would work. If you are running setup, you have already extracted the new core in its default location.

[Jako]

At least the core/packages and maybe some parts of the core/cache content could be moved to the new location during the setup. The other parts normally don't have to be touched.

[rthrash]

Got my PR in for the docs: https://github.com/modxorg/Docs/pull/280 … that took _way_ longer than I thought. LOL

@wuuti would appreciate your thoughts on it. I completely re-organized the page to focus on MODX first since that's what most folks reading that type of page will really be looking for and addressed the 2 vs 3 issues we're currently facing.

I didn't add anything to address what @Jako pointed out but that probably should be added. A quick rsync recipe for core/packages would be useful.

[wuuti]

My thoughts so far:

• we should create a _config check_ for the 2.x branch, which checks if the installation is hardenend and warns that the upcoming 3.x version won't work with that, showing a link to a documentation how to mitigate that. Imho such config checks for upcoming versions should be available in the future (like the "upgrade advisor" used in elasticsearch). Such an upgrade advisor could also contain more information (incompatible packages, etc), which will surely be found in the near future.
• we may rethink the whole setup concept imho. @opengeek is right, once the user sees the setup, a lot is already done (except db maybe) So if something goes wrong during the setup, or any of the already implemented checks there fail, the user is left with a "half-installed" and possibly broken installation, because the files have already been "merged", a step which cannot be undone easily without restoring a whole backup. From my thoughts an update setup should work like this:
  
  
  
  • the whole downloaded tarball is extracted to a separate folder (and not "merged" into an existing installation)
  
  
  • you start the setup from there
  
  
  • the setup can check _everything_ in advance then, _before_ actually something has been changed
  
  
  • the setup should create a rollback point (or at least offer it), which is dumping the db and creating a copy of the important files
  
  
  • if something goes wrong during the update, the setup should offer to rollback the stuff to the previous restore point (the rollback should also be possible later, e.g. if you see unsolvable problems with your updated installation later und go back to the locked setup then)
  
  
  • if something like a hardened installation is detected during setup, which is automatically fixable, the setup could directly offer to do that, or at least give a step by step documentation how to solve the problem
  
  
  • if everything is checked fine, the setup then itself copies/merges files to the final destination and starts the db migration
  
  

I am aware of the fact this may start a lot of discussion, and the setup things should better continued in a separate issue then. But having a new major version imho is the best time to introduce also conceptual changes in this part of modx, maybe not all at once, but step by step....

[JoshuaLuckers]

• we should create a _config check_ for the 2.x branch, which checks if the installation is hardenend and warns that the upcoming 3.x version won't work with that, showing a link to a documentation how to mitigate that. Imho such config checks for upcoming versions should be available in the future (like the "upgrade advisor" used in elasticsearch). Such an upgrade advisor could also contain more information (incompatible packages, etc), which will surely be found in the near future.

I like the idea but I don't think it's a good idea to have it part of the core:

• If we add the config check in 2.x, users need to update to this particular 2.x release first.
• Updating the config check with new checks also require a new MODX release.

An extra would be much better because it doesn't require users to update MODX first and we can update it independently from MODX.