search

efdevcon / pretix-attestation-placeholder-plugin

Pretix plugin to support placeholders for attestations
MIT License
2 stars 7 forks source link

Implementation #1

Closed ligi closed 3 years ago

ligi commented 3 years ago

Create a pretix placeholder plugin as documented here

The placeholder should then invoke the tool provided by alphawallet to create the links as outlined in DIP-6 as the placeholder. An alternative (as the tool provided will be written in java) is to re-implement it in python to not have the complexity of crossing the python<>java bridge.

SmartLayer commented 3 years ago

What is your thinking on the proposal that STJ originally had, that is deploying the TicketIssuer as an AWS Lambda? Thanks to microarchitecture different language components can work together if all implementing the AWS SDK. There are 2 approaches: Python code will do either š¯‘ˇ or š¯‘¸

š¯‘ˇ) call the AWS Lambda and obtain the resulting ticket, then, in turn, sends the email; š¯‘¸) call the AWS Lambda who will be sending the email and logging it in AWS event log; optionally a message queue is set so any follow-up actions can be done on pretix.

As of the python<>java bridge, if we go that route, the steps would be writing a simple Python plug that calls a Java class which returns a random string as the ticket link; observe how the jar file is built, and build another using the ticket demo code from our repo.

ReĆÆmplement in Python has its intricacy to deal, and added maintenance. But I would support this route if there is an aspiring developer who wishes to crack this nut and level up his crypto-fu seriously, and who has the capacity to fix it if it was found broken in the middle of Devcon preparation.

ligi commented 3 years ago

Thanks for the input. Yea the re-implementation was just an idea when the complexity is low. Does not seem to be that way - so I think option (a) is the way to go. I do not think (b) would work from an UX perspective as it would mean 2 emails to the user. The only issue I have with calling an external service is what happens if it is down? Not really sure how retry mechanisms work in case of a pretix-placeholder-plugin. Also leaving these links here that you send via email for more context in this issue:

ligi commented 3 years ago

after talking to @raphaelm from pretix: we should invoke the lambda on the signal order_placed and save the result. Then in the placeholder plugin we fetch the value that was stored.

SmartLayer commented 3 years ago

after talking to @raphaelm from pretix: we should invoke the lambda on the signal order_placed and save the result. Then in the placeholder plugin we fetch the value that was stored.

It's the cleanest, but I got this information:

AWS Lambda is known to underperform the advertised standard with this problem: that the first person who accessed a lambda in a while may experience ~30 seconds delay (not failed - just delay).

If the Pretix system can't wait that long (e.g. if the backend is designed to live as long as the frontend web page) we can't go that route. If this is an issue for pretix, we might resort to a Java-based web service which unfortunately introduce the downtime possibility (lambda on the other hand has a negligible chance of failure because it works as long as AWS Lambda is online; where web service in an EC2 instance depends on many factors and may stop working even if all AWS EC2 services are online).

ligi commented 3 years ago

Maybe we can run it in the same EC2 instance as our pretix runs in (AFAIR it does - but @kvbik can confirm) But we also should have a backup plan in case something is wrong with the link generating service (perhaps some fallback URL with explanation / retry options). The most important thing is that the confirmation mail goes out - the link generation MUST not prevent this.

skylarweaver commented 3 years ago

@ligi this was an option mentioned by Pretix support: _An alternative might be calling the function in e.g. the orderplaced signal and storing the result somewhere, depending on in which email you need the placeholder to work.

What are the thoughts on this idea? They make it sound like the order_placed signal handles network I/O better? Not sure if that's actually the case though.

ligi commented 3 years ago

yea - as mentioned here I think we should do this. This way we also only call it once and not multiple times as if we would do it in the placeholder plugin directly.

ligi commented 3 years ago

let's continue the discussion in #6 and keep the issue tracker for issues. I created a initial milestone (0.1) with these issues:

3 #2 #4 #7