Doctrine DBAL will remove its event system in version 4.0 and logs deprecation warnings whenever code uses the event system. Our code uses the event system to generate access and update tokens for donations and memberships when they are saved. To avoid filling our log files with deprecation warnings (which make debugging harder because they clutter the log files and may lead to false assumptions) and make our code ready for updating to Doctrine version 4, we need to change the way how and when we store security tokens.

Background information
When we wrote the Fundraising Application and created the domain model, we did not want to "pollute" our domain object (Donation) with HTTP-specific access control properties, so we opted for "sneaking them in" through the Doctrine entity when the donation is saved.

Solution
We still want the general concept of access control (in this case "the owner has a token that allows them access") inside our use cases. We need to pass an interface into the AddDonation and AddMembership use cases that'll allow us to create the credentials.

Currently, the TokenFetcher dependency of the use case exposes the existence of tokens to the domain. With the refactorings for the Paypal API we'll use a system that doesn't expose concepts like tokens on the wrong layers.

Acceptance criteria:

• The deprecation warning for the event system no longer occurs

Non-Goals:

• Extracting the access tokens from the data blob in spenden into their own table - This would be too much effort right now. However, make sure that there is only one class for interacting with the database, so they can be swapped out in the future.

Implementation details:

When integrating the changed bounded contexts into the Fundraising App, you can remove event-related code from ContextFactoryCollection, DoctrineFactory and FunFunFactory. In FunFunFactory, getPlainEntityManager can become the new getEntityManager.

The Fundraising Operation Center does not need any changes - it doesn't call the "Add Donation" and "Add Membership" use cases and doesn't initialize Doctrine with event subscribers.

Suggested Approach for generating tokens inside the "create" use cases:

• The payment bounded context has an interface addAuthenticationTokensToUrl (for meodifing application URLs) and getAuthenticationParametersForPaymentProvider (for passing authentication parameters to payment providers that return them as URL/Form parameters when sending a notification)
• The membership and donation bounded contexts have interfaces that can "announce" an entity to the authentication layer (e.g. createAuthorizationForDonation(id) and createAuthorizationForMembership(id)). These methods might be added to the existing DonationAuthorizer and MembershipAuthorizer interfaces.
• The Fundraising Application has an authorizer implementation of the 3 interfaces. It creates in-memory tokens when the createAuthorizationForDonation(id) and createAuthorizationForMembership(id) are called and appends them to URLs. The authorizer should also implement event handlers for the "donation created" and "membership crated" *domain* events to write the in-memory tokens to the database (see FunFunFactorysetupEventListeners).
• The addAuthenticationTokensToUrl implementation will take over some of the functionality of the UrlGenerators in the payment domain (because in the long run we want to be more flexible with our Application-Level URL parameters and should not encode them in the Payment bounded context). This means we'll have to check the target URL (with URL values from the payment section if the application configuration) and append the right parameters:
  • application domain (test-spenden-2.wikimedia.de, spenden.wikimedia.de, etc): check the path and append path-dependent parameters:
    • donation-confirmation: append accessToken
    • handle-paypal-payment-notification accessToken

the getAuthenticationParametersForPaymentProvider method needs to look at the url provider class and return the following parameters

• CreditCardURLGenerator: token (accesstoken), utoken (update token)
• LegacyPayPalURLGenerator:custom, a a json-encoded parameter with an object that has (sid (donation id) and utoken (update token)).

You need to test if the payment and notification flows are still working!