act-now-coalition / act-now-links-service Goto Github PK

Find the best way to document this kind of API and write the documentation (could maybe just go in the README)

We should replace the current Firebase ID Token script and endpoints with a web UI using google auth sign on

• Prettier #40
• ESLint

Currently we're running everything off of act-now-links-dev. We should create an act-now-links-prod project, and update the production pointers/config in the repo to point at it

Per warning:

Authenticating with `--token` is deprecated and will be removed in a future major version of `firebase-tools`. 
Instead, use a service account key with `GOOGLE_APPLICATION_CREDENTIALS`: 
https://cloud.google.com/docs/authentication/getting-started

token-based auth is deprecated and we should switch to using a service account.

We will need to create a new service account, add that as a repository secret (where the FIREBASE_CI_TOKEN secret currently lives), and update our Github Action workflows to use it instead of the token (presumably with an env variable)

Screenshots are slow atm, which can cause issues with using them to generate preview images

Pull requests to develop should deploy functions to act-now-links-dev and PRs to main to act-now-links-prod (once it's created)

See: https://www.w3.org/TR/2016/NOTE-WCAG20-TECHS-20161007/SVR1

Requests to the links service began failing unexpectedly (without any changes as far as I can d) due to a CORS issue.

Requests succeed in CORS testers.

Example of blocked/failed request:

Note the 301: Permenantly Moved response; AFAIK this request shouldn't be making any redirects. It's possible that if the request is being redirected (though I don't think it should be) and the access-control-allow-origin: * header is being lost/not forwarded, resulting in the request being blocked.

Right now we detect the "url param" using a wildcard at the end of the URL, which avoids encoding issues, but is hacky and prone to issues.

using encode/decodeUriComponent() should allow us to pass URLs into formal URL query parameters, giving us more stability.

e.g. use https://www.api-service?url=<encoded-url as opposed to https://www.api-service/<unencoded-url>

Anecdotally we know it's possible b/c e.g. https://cors-test.codehappy.dev/?url=https%3A%2F%2Fus-central1-act-now-links-dev.cloudfunctions.net%2Fapi%2FgetShareLinkUrl%2Fhttp%3A%2F%2Fhackathon-september-2022-4dve.vercel.app%2F%2F%2Fus%2Farkansas-ar-pope-county&method=get uses this method

Per comments on #44, it would be nice to have the class names used to detect if the screenshot target page is loading be configurable/not directly tied to act-now

Require an auth token (or similar) when registering share links.

Need to think about how to approach this in a way that allows us to keep tokens secret/secure in the frontend apps

to have URLs look something like sharing.actnowcoalition.org/url as opposed to https://us-central1-act-now-links-dev.cloudfunctions.net/api/url (how they currently look)

As discussed at standup, I think we could have two classes that we use in our components that asynchronously load data:

• act-now-data-loading - used initially before data is loaded / ready.
• act-now-data-loaded - used after data is rendered and it's safe to take a screenshot.

And the link service could wait until:

1. At least one instance of act-now-data-loaded exists on the page.
2. No instances of act-now-data-loading exists on the page.

Then you can just use our components in your share image, and it'll "just work" without any logic / mutation observers, etc...

Currently the share links only use open graph tags, which Twitter doesn't seem to support.

We should probably add all the tags found in https://github.com/covid-projections/act-now-template/tree/develop/src/components/SocialMetaTags

There's a possible race condition where two share links can be created for the same URL if two requests are made near simultaneously. We expect there to only ever be one share link per URL.

Can maybe do this by seeding the "random" hash/share link ID with the url? This will prevent multiple share links from being created, but still has issues. If two requests are sent simultaneously to create a share link for the same URL but otherwise different params, I'm not sure which data will be saved? Will a collision cause undefined behavior?

Add unit tests for each API endpoint