There were a few things which made this rather difficult:
- AWS SDK doesn't appear to have a utility to validate message
signatures.
- The only available node.js module that does this is known to be
unreliable.
- SNS sends 'text/plain' MIME type even though the data is in JSON
format, so a middleware had to be added to account for this.
- We don't accept POST requests with no Origin header. Since SNS doesn't
send the Origin header, an exception had to be made for this.
- The endpoint needs to be public and SNS doesn't seem to have a
proxying utility for developers such as what Stripe has.
- Because of the above point, debugging time was affected by deployment
time to the staging server.
This commit fixes the timing of the /whoami call used for the
PrefixLogger (a logger for puter.js that displays app names) to ensure
the API origin and token are available. This is done by waiting for a
service called 'api-access' to be initialized first.
This was discovered while testing changes for /whoami responses that
display icons, because the current behavior breaks the call for
non-puter.com instances.
Calls to `/whoami` generally don't require app icons. Fetching icons of
the smallest size still incurs round-trip latency from the database and
S3, as well as additional delay for any retries due to failed icon
generation.
Although this is technically a regression in `/whoami`, the impact is
localized to Puter's desktop only because apps are not allowed to
receive taskbar icons.
Current issue with get-launch-apps wasn't fixed by catching errors while
reading the stream so this next attempt catches errors from the call to
start reading.
If the error occurs asynchronously this may not work either.
This happened because the return signature of get_app_icon was changed
so that the MIME type can be returned when the uploaded or default icon
is being used as a fallback. AppES was not updated to account for this
change.