3

so I'm building a tool to increase security of a website. The tool is loaded before the CMS is started and will scan the Request for problematic content (like a soft firewall)

The thing is - I used some libs over Composer to build the tool. So far so good. Right now I'm thinking that might be a bad idea because if the CMS calls Composer Autoload as well, we will have maybe different versions of the same libs in the code (which will create problems and errors).

So is there a way to unload my composer autoload after my script is finished with scanning the request?

Thank you for any help :)

OmegaTCU
  • 108
  • 4
  • 1
    Im wondering why you didn't integrate your tool into the CMS but developed it as a seperate tool? – Xatenev Oct 06 '16 at 09:42
  • Use a seperate vendor directory so you don't get path conflicts and use `$functions = spl_autoload_functions(); foreach($functions as $function) { spl_autoload_unregister($function); }` – Xatenev Oct 06 '16 at 09:44
  • @Xatenev I want to use this tool on other websites in the future too. so it has to be CMS unspecific. – OmegaTCU Oct 06 '16 at 09:50

3 Answers3

0

well composer generates an autoload.php in your vendor folder. And every composer call will overwrite the autoload.php.

You just could use a seperate folder for your own vendors, and it's fine.

You also can change the folder to use with "installer-paths" in your composer.json.

Gladhon
  • 211
  • 2
  • 5
  • Thank you I already use a different vendor dir. But i Thought the autoload would then go to my dir instead of the Vendor dir of the cms. – OmegaTCU Oct 06 '16 at 09:48
  • okay, how you start your soft-firewall? - i would recommend some kind of process isolation. ( like PhpProcess ) – Gladhon Oct 17 '16 at 11:47
0

Yes, you can unregister autoload functions as follows:

$functions = spl_autoload_functions();
foreach($functions as $function) {
    spl_autoload_unregister($function);
}

Source: http://php.net/manual/en/function.spl-autoload-unregister.php#112225

However, this will not leave you with a clean slate (which is what you want):

  • you will have to unset any global variables
  • some libraries may define constants, and there is no way for you to unset and/or modify those (source)
  • any classes that you load in your code will remain loaded during the lifetime of the request, and as far as I know there is no way to unload them (source)

Your best bet is to integrate your code into said application (i.e. merge composer files) and keep the versions in sync while doing maintenance of your application.

Community
  • 1
  • 1
MicE
  • 5,038
  • 2
  • 29
  • 26
  • okay - so can I use namespaces for this so i don't get in conflict with other calls from the Website? – OmegaTCU Oct 06 '16 at 09:51
  • For your own code, yes. However let's say that some library that you installed via composer loads a class Foo\Bar. You unregister the autoload, but `Foo\Bar` class definition remains loaded. When the CMS that runs afterwards asks for `Foo\Bar` will receive the one loaded by your code. Hence the proposal to merge your composer files and keep the lib version in sync (see my edits). Yes, this may result in a dependency hell, but as long as you keep your composer libraries locked to stable version/tags, it should be manageable. – MicE Oct 06 '16 at 09:56
0

Nice question. I faced similar problem when 2 places in my code used different versions of guzzle. So, you can not unregister already registered classes at runtime. You can't clean runtime from your firerwall's footsteps. And so, you can't be sure that your product will be compatible and non-conflicting wherever it will be used. Sad, but true.

Bogdan Burym
  • 5,482
  • 2
  • 27
  • 46
  • So my solution for this one project will be to merge the composer together. For everything else I will need to write my own classes for it to work. If I only use my own solutions I should not have said problem with composer. This ofc comes with other issues... – OmegaTCU Oct 06 '16 at 12:31