Allow specifying delivery whitelists for the redirect plugin #19

lstrojny · 2012-08-21T21:15:50Z

This PR is related to swiftmailer/swiftmailer#234 and allows Symfony users to configure delivery whitelists for the SwiftMailer RedirectingPlugin.

stof · 2012-08-21T21:27:01Z

DependencyInjection/SwiftmailerExtension.php

@@ -126,6 +126,13 @@ public function load(array $configs, ContainerBuilder $container)
        } else {
            $container->setParameter('swiftmailer.single_address', null);
        }
+
+        if (isset($config['delivery_whitelist']) && $config['delivery_whitelist']) {


it will always be set as a prototyped array node defaults to an empty array. So setting the parameter can be done by $container->setParameter('swiftmailer.delivery_whitelist', $config['delivery_whitelist']); for all cases.

And I don't think it makes sense to enable the plugin if the delivery_address is not set but only the whitelist (I even think that it may break things when sending a mail to a non-whitelisted message).

Alright, fixed.

lstrojny · 2012-08-22T08:29:23Z

Squashed. Ready to merge from my POV.

stof · 2012-08-22T08:31:24Z

no, it is not ready as the Swiftmailer PR is not merged yet :)

fabpot · 2012-08-22T10:23:51Z

The Resources/config/schema/swiftmailer-1.0.xsd file must be updated too for people using XML as a configuration format.

lstrojny · 2012-08-22T12:43:47Z

@fabpot can you point out an example of a list definition in an xsd?

lstrojny · 2012-08-22T15:54:16Z

@fabpot, @stof I'm not 100% sure with the XSD, could you have a look?

fabpot · 2012-08-22T16:00:29Z

Resources/config/schema/swiftmailer-1.0.xsd

@@ -62,4 +63,10 @@
      <xsd:enumeration value="none" />
    </xsd:restriction>
  </xsd:simpleType>
+
+  <xsd:complexType name="delivery_whitelist">


should be "delivery-whitelist" (notice the dash instead of the underscode)

I can change that, but it’s the same convention as in auth-mode (the name) vs. auth_mode (the type).

lstrojny · 2012-08-22T16:06:03Z

PR squashed.

stof · 2012-08-22T16:13:57Z

Resources/config/schema/swiftmailer-1.0.xsd

+    <xsd:sequence>
+      <xsd:element name="pattern" type="xsd:string" minOccurs="0" maxOccurs="unbounded" />
+    </xsd:sequence>
+  </xsd:complexType>
 </xsd:schema>


this is not the right thing. It will not work properly (add some unit tests loading a file with a whitelist containing 1 element and with a whitelist with several elements and you will see it fail).
This is an prototyped array node, so it should simply be a direct child of the config appearing many times (to be consistent with the other places using it and avoiding a hack to remove the extra level when coming from XML), and then using ->fixXmlConfig in the Configuration class (which is needed as XML would give us a different result for a single element or a collection of elements so we need tell the processor to take care of it)

stof · 2012-08-22T16:15:17Z

btw, if you want an example loading fixture files in the testsuite, look at the MonologBundle setup

lstrojny · 2012-08-28T19:27:04Z

Added a bunch of unit tests for various configuration scenarios. Could you review again?

stof · 2012-08-28T20:48:57Z

Please also add a test with a single entry in the whitelist as it is a different case in XML

stof · 2012-08-28T20:50:28Z

Tests/DependencyInjection/SwiftmailerExtensionTest.php

+        $container->setParameter('kernel.cache_dir', '/tmp');
+
+        $container->registerExtension(new SwiftmailerExtension());
+        $locator = new \Symfony\Component\Config\FileLocator(__DIR__ . '/Fixtures/config/' . $type);


Please add a use statement for the class

lstrojny · 2012-08-28T21:20:30Z

Fixed. Thanks for the heads up regarding XML configuration.

lstrojny · 2012-08-28T21:22:53Z

Schema uses xsd:all egain. Unused use statement removed.

lstrojny · 2012-08-28T21:23:25Z

So, ready for (hopefully) final review.

lstrojny · 2012-08-28T21:25:03Z

Squashed to ease review.

stof · 2012-08-28T21:33:49Z

DependencyInjection/Configuration.php

@@ -62,6 +62,8 @@ public function getConfigTreeBuilder()
                        ->thenInvalid('The %s encryption is not supported')
                    ->end()
                ->end()
+            ->end()
+            ->children()


this is useless. Please revert it

stof · 2012-08-28T21:41:12Z

note that if the XSD does not allow to allow any number of whietlist-pattern chidlren (or whatever their name) andonly a single antiflod, it is not a big deal. The XSD should be as good as possible so that the autocompletion is good, but the final validation is handled bythe Configuration class anyway

lstrojny · 2012-08-28T21:44:31Z

That’s actually the XSD for the pattern element, not the delivery_whitelist element. That's why it is unbounded. The delivery_whitelist element is only allowed once (as are spool and antiflood).

lstrojny · 2012-08-28T21:50:31Z

To demonstrate, added full.(xml|yml|php) test case.

stof · 2012-08-28T22:12:11Z

@lstrojny exactly, and this is not consistent with all the other Symfony configurations for their XMLr representations.
The previous one was better, even if the XSD was not perfect but I'm not sure it is possible to make it perfect (and I think there was a buggy case to fix).

stof · 2012-08-29T08:26:38Z

@lstrojny The master branch now has a Travis config. Please rebase your branch so that it can test the PR:

$ git fetch upstream
$ git rebase upstream/master
$ git push origin delivery-whitelist --force

lstrojny · 2012-08-29T10:40:35Z

Done.

travisbot · 2012-08-29T10:40:53Z

This pull request fails (merged 4addbfe into fcacc9e).

lstrojny · 2012-08-29T10:42:01Z

@stof anything I can do about the failing pull request.

stof · 2012-08-29T10:57:34Z

oups, I forgot the minimum-stability. Please add "minimum-stability": "dev" in the composer.json (you can do it in this PR)

lstrojny · 2012-08-29T11:00:33Z

Done.

travisbot · 2012-08-29T11:01:56Z

This pull request passes (merged 7067ca9 into fcacc9e).

stof · 2012-08-29T11:02:56Z

@lstrojny now, you still need to take into account my previous comment about the XML config and it will be fine

lstrojny · 2012-08-29T11:08:19Z

OK, here is the alternative which I find way worse:

<swiftmailer:config>
   <swiftmailer:delivery-whitelist-patterns>
      <swiftmailer:delivery-whitelist>/foo\.com$/</swiftmailer:delivery-whitelist>
      <swiftmailer:delivery-whitelist>/bar\.com$/</swiftmailer:delivery-whitelist>
   </swiftmailer:delivery-whitelist-patterns>
<swiftmailer:config>

And in YAML:

swiftmailer:
  delivery_whitelist_patterns:
    - /foo\.com$/
    - /bar\.com$/

Both variants are worse than what we currently have.

stof · 2012-08-29T11:21:32Z

I would keep a singular in YAML (there is only 1 whitelist) and use

<swiftmailer:config>
   <swiftmailer:delivery-whitelist-pattern>/foo\.com$/</swiftmailer:delivery-whitelist-pattern>
   <swiftmailer:delivery-whitelist-pattern>/bar\.com$/</swiftmailer:delivery-whitelist-pattern>
<swiftmailer:config>

This would allow you to simplify the Configuration class (the only thing needed to support the XML config is ->fixXmlConfig('delivery_whitelist_pattern', 'delivery_whitelist'))

stof · 2012-08-29T11:22:29Z

Btw, looking at your proposal, it is still not following what I asked several types about prototyped array nodes as you are still suggesting a wrapper node :)

lstrojny · 2012-08-29T11:30:46Z

Alright, I can change that but I feel that the XML is much less XMLish (if that’s even a word).

lstrojny · 2012-08-29T11:53:31Z

So, the from my POV worse XML structure is implemented. We need to use a <xsd:choice/> instead of <xsd:all/> there to allow unbounded <delivery-whitelist-pattern/> which forces an order of elements.

travisbot · 2012-08-29T12:01:30Z

This pull request passes (merged 3930be7 into fcacc9e).

stof · 2012-08-29T12:02:00Z

@lstrojny why much less XMLish ? XML does not require a wrapping tag around a set of children, and this will now be consistent with the way it is done everywhere else in Symfony

lstrojny · 2012-08-29T12:11:14Z

It just doesn’t feel like idiomatic XML. Have a look at MathML, XHTML, Docbook, SOAP etc. If there is a list, it’s always <list><item/></list>. But it’s not worth a fight. If that's the way Symfony wants its XML configuration structured, let’s do it that way. I don’t need to agree.

Allow specifying delivery whitelists for the redirect plugin

@cordoval

…ct (TerjeBr) This PR was submitted for the 2.6 branch but it was merged into the 2.3 branch instead (closes #4924). Discussion ---------- [swiftmailer] Document whitelist option to email redirect The redirectPlugin in switfmailer allows you to specify a white-list of regex's that matches email addresses that are still sent to, when redirecting all email to one address. Code was added in PR [switfmailer/SwiftmailerBundle#19](symfony/swiftmailer-bundle#19) Commits ------- 1448f58 More xml fixes 16907ed Xml changes and line-break changes 747199c Swiched mydomain and specialdomain c35a26f Changes recommended by @cordoval 8c1da8a Changes recommended by @javierguiluz 4aa58a4 Changed line-breaks in text 217811d Added improvments from @wouterj a4af6a0 fixed typo in "except" 6f64fdb Document whitelist option to email redirect

stof reviewed Aug 21, 2012
View reviewed changes

fabpot reviewed Aug 22, 2012
View reviewed changes

stof reviewed Aug 22, 2012
View reviewed changes

stof reviewed Aug 28, 2012
View reviewed changes

lstrojny added 3 commits August 29, 2012 12:40

Allow specifying delivery whitelists for the redirect plugin

79785db

Removing porcelain

fd28977

Adding full config file

4addbfe

Adding minimum stability to the composer.json

7067ca9

Worsen XML structure

3930be7

stof added a commit that referenced this pull request Aug 29, 2012

Merge pull request #19 from lstrojny/delivery-whitelist

d2eae93

Allow specifying delivery whitelists for the redirect plugin

stof merged commit d2eae93 into symfony:master Aug 29, 2012

TerjeBr mentioned this pull request Jan 26, 2015

[swiftmailer] Document whitelist option to email redirect symfony/symfony-docs#4924

Closed

Allow specifying delivery whitelists for the redirect plugin #19

Allow specifying delivery whitelists for the redirect plugin #19

Conversation

lstrojny commented Aug 21, 2012

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lstrojny commented Aug 22, 2012

stof commented Aug 22, 2012

fabpot commented Aug 22, 2012

lstrojny commented Aug 22, 2012

lstrojny commented Aug 22, 2012

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lstrojny commented Aug 22, 2012

Choose a reason for hiding this comment

stof commented Aug 22, 2012

lstrojny commented Aug 28, 2012

stof commented Aug 28, 2012

Choose a reason for hiding this comment

lstrojny commented Aug 28, 2012

lstrojny commented Aug 28, 2012

lstrojny commented Aug 28, 2012

lstrojny commented Aug 28, 2012

Choose a reason for hiding this comment

Choose a reason for hiding this comment

stof commented Aug 28, 2012

lstrojny commented Aug 28, 2012

lstrojny commented Aug 28, 2012

stof commented Aug 28, 2012

stof commented Aug 29, 2012

lstrojny commented Aug 29, 2012

travisbot commented Aug 29, 2012

lstrojny commented Aug 29, 2012

stof commented Aug 29, 2012

lstrojny commented Aug 29, 2012

travisbot commented Aug 29, 2012

stof commented Aug 29, 2012

lstrojny commented Aug 29, 2012

stof commented Aug 29, 2012

stof commented Aug 29, 2012

lstrojny commented Aug 29, 2012

lstrojny commented Aug 29, 2012

travisbot commented Aug 29, 2012

stof commented Aug 29, 2012

lstrojny commented Aug 29, 2012