Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Injection Inception, Change #5: Add Access and Auth objects to DI #8026

Merged
merged 9 commits into from Jun 4, 2015

Conversation

diosmosis
Copy link
Member

This PR is based off of #8008, so that PR must be merged first.

This PR includes the following changes:

  • Change Access from being a singleton to being in DI.
  • Change the Login plugin so it defines the Auth implementation in DI, instead of the Request.initAuthenticationObject event.
  • Fixed lots and lots of tests.

@diosmosis diosmosis added c: Platform For Matomo platform changes that aren't impacting any of our APIs but improve the core itself. Needs Review PRs that need a code review labels Jun 1, 2015
@diosmosis diosmosis added this to the 2.14.0 milestone Jun 1, 2015
Access::getInstance()->setSuperUserAccess(true);
})
)),
));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to be sure I understand this correctly: the container is already created at that point so in theory this wouldn't work. But in this command we include index.php so it will re-create a whole environment (and container), so this works. Is that right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The container is created in Console, then RequestCommand creates a new one for RequestCommand stuff (mainly because the Cache is created in UrlHelper), then it includes index.php which creates the environment again. And the last environment creation is where we want to set superuser access.

When the web app frontend is encapsulated, it will look a lot better, eg:

$webApp = new WebApplication();
$webApp->getEnvironment()->getContainer()->get('Piwik\Access')->setSuperUserAccess(true);
$webApp->dispatch(...);

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

@mnapoli
Copy link
Contributor

mnapoli commented Jun 1, 2015

Looking good, once #8008 is merged the diff should be simpler to read (going commit by commit was easy).

The Access.createAccessSingleton event was removed, it should be added to the changelog. Will it break plugins?

Also previously plugins had to do StaticContainer::getContainer()->set('Piwik\Auth', $auth) to set their own auth, will this change break BC? I don't think so (because $container->set() overrides what's in DI config so all good), but I guess you have tested maybe with LoginLdap? And we still document for plugins to use $container->set() and not use DI config right? Because right now the status is that 3rd party plugins don't know about DI config, so it's better not to change that for now. (however we can use DI config in plugins in our own plugins)

@diosmosis diosmosis self-assigned this Jun 1, 2015
@diosmosis
Copy link
Member Author

The Access.createAccessSingleton event was removed, it should be added to the changelog. Will it break plugins?

It was never documented so it shouldn't be part of the public API. It's used by a PRO plugin, though.

Also previously plugins had to do StaticContainer::getContainer()->set('Piwik\Auth', $auth) to set their own auth, will this change break BC?

It shouldn't. LoginLdap actually only uses DI, so I think it will work both ways.

And we still document for plugins to use $container->set() and not use DI config right?

I'm not sure what the status of DI is as it relates to 3rd party plugin development, so I don't have an opinion on this.

@mnapoli
Copy link
Contributor

mnapoli commented Jun 1, 2015

LoginLdap actually only uses DI, so I think it will work both ways.

Good! Currently 3rd party plugins shouldn't use DI config, but being able to use it for our plugins is great. Nice change!

@mnapoli
Copy link
Contributor

mnapoli commented Jun 3, 2015

I think this PR should be rebased on master now that #8008 has been merged -> the PR contains commits of #8008. I guess #8008 might have been rebased after this branch was created, so this branch contains the old commits (of before the rebase). Be careful when rebasing: commits of #8008 should be skipped so that they are removed from this branch (else they'll be applied twice).

@diosmosis
Copy link
Member Author

I rebased both branches when rebasing #8008, so should be ok.

diosmosis added 8 commits June 3, 2015 10:01
… password/password hash (which can be set to previous values in tests during local tracking) and allow these values to be set to null in corresponding set methods of Login's Auth class.
…removed when the environment is recreated. So now in RequestCommand when the container is recreated, the Access instance is destroyed and the doAsSuperUser call is negated.
@diosmosis
Copy link
Member Author

After this is merged, this PR in the CustomAlerts repo must be merged as well: matomo-org/plugin-CustomAlerts#15

mnapoli added a commit that referenced this pull request Jun 4, 2015
Injection Inception, Change #5: Add Access and Auth objects to DI
@mnapoli mnapoli merged commit b0bb344 into master Jun 4, 2015
@mnapoli mnapoli deleted the test_env_di_7 branch June 4, 2015 08:17
mnapoli added a commit to matomo-org/plugin-CustomAlerts that referenced this pull request Jun 4, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
c: Platform For Matomo platform changes that aren't impacting any of our APIs but improve the core itself. Needs Review PRs that need a code review
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants