Presently, the giveaway summary file produced at the end of a giveaway is a standard .json file. This is fine, mostly, but since Discord enforces CORS on their cdn, a third-party service is required to load the summary web page (which bypasses the CORS headers and provides the raw json).
Switching GiveawayBot to produce jsonp (json-with-padding) output would allow the summary page to load the summary directly from Discord's cdn, as <script> tags (the underlying tool used for loading jsonp files) ignores CORS.
A few caveats:
The system needs to be backwards-compatible. If someone tries to load an older json-style summary, the site will still need to use a third-party url.
This will require either a new query parameter in the summary url (such as &v=2) to signify the new system, or a new summary page entirely (/giveaway-summary, for example). I'm leaning towards a query parameter to be more future-proof if more summary loading methods are used in the future.
Presently, the giveaway summary file produced at the end of a giveaway is a standard
.json
file. This is fine, mostly, but since Discord enforces CORS on their cdn, a third-party service is required to load the summary web page (which bypasses the CORS headers and provides the raw json).Switching GiveawayBot to produce jsonp (json-with-padding) output would allow the summary page to load the summary directly from Discord's cdn, as
<script>
tags (the underlying tool used for loading jsonp files) ignores CORS.A few caveats:
&v=2
) to signify the new system, or a new summary page entirely (/giveaway-summary
, for example). I'm leaning towards a query parameter to be more future-proof if more summary loading methods are used in the future.