googlechromelabs / lighthouse-keeper Goto Github PK

Hello,

I tried to run the service locally; However I can't because

You will be prompted to for a passphrase to decrypt serviceAccount.json.enc and memcacheCredentials.json.enc. These files are required for the backend to communicate with Firestore and the Redis memcache service. The password can be found in Google's shared password tool.

so I guess this project was an internal thing and now it's something public on the internet.

How to make possible run my own version of the service? What's the format the configuration file should be followed?

Ewa put in deletion APIs for the cron. We can reuse those:

await Promise.all(urls.map(url => {
  return lighthouse.deleteReports(url).then(() => lighthouse.deleteMetadata(url));
}));

Hi, I am following with README to decrypt the service account and memcache JSON files
when I set a simple passphrase, I got error as below:

enter aes-256-cbc decryption password:
bad decrypt
4521469548:error:06FFF064:digital envelope routines:CRYPTO_internal:bad decrypt:/BuildRoot/Library/Caches/com.apple.xbs/Sources/libressl/libressl-22.260.1/libressl-2.6/crypto/evp/evp_enc.c:533:

I would like to know is this passphrase connectted with other account or just simple passphrase for my local.

For dev/testing, it would be a good idea to keep our prod data separate from dev. Especially once we have users :)

• Cloud storage buckets for dev/prod. (Already have buckets defined for prod (webdotdevsite.appspot.com) and staging (staging.webdotdevsite.appspot.com)
• Firestore urls for dev/prod. Need to set this up.

And probably control it with an ENV flag when you start server.mjs.

If an owner pings us and asks that we prevent anyone from tracking their URL, we should be able to blacklist it and inform folks with an error message. E.g. "The owner of this domain has disabled tracking for it." or something like that.

To count the number of URLs in the system, lighthouse-keeper does a cron which queries the db in 5000 record chunks. It seems like a more efficient approach might be to use the FieldValue API to increment a counter whenever a record gets added, and to decrement the counter when old records get removed.

A user should only be able to see historical data for a URL from the point in which they began tracking it. They should not be able to use something like curl to send a timestamp that's one day earlier and see the previous day's results.

In lighthouse-data.mjs there are opportunities to parallelize some of the promises in saveReport. We touch memcache, firestore several times, and cloudstorage to update metadata, cache entries, and (re-save) reports.

We could push some of these onto an array and use await Promise.all().

I'll explore this once https://github.com/GoogleChrome/lighthouse-keeper/pull/10/files is in. Want to benchmark it too :)