Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

report: save to trace-cafe storage for auth-less permalinks #15620

Open
wants to merge 10 commits into
base: main
Choose a base branch
from

Conversation

paulirish
Copy link
Member

@paulirish paulirish commented Nov 17, 2023

The save as gist workflow has always been complicated.

  1. You always have to go to the viewer webapp.
  2. You see "save as gist" when the feature is really "Get a sharable permalink"..
  3. You authenticate through firebase to talk to... github.?!?! 😖

anyway.. this is a single fetch() POST to upload and no auth needed. 💅


image

a few moments later:

image

why https://trace.cafe? I'm using a bucket within the trace-cafe project only because there we already figured out the protected permissions and 365 day TTL stuff. the user doesn't see trace cafe.. heck the URL under the hood is something like https://firebasestorage.googleapis.com/v0/b/tum-lhrs/o?name=lhrs%2Fl<ID>.. but anyway..

This PR drops the upload-as-gist functionality. However apparently we still need firebase/github auth to download gists.. (We really shouldn't, but the PR was getting big already).

Followups:

  • we can move this feature to the dropdown of all reports (except on file:// protocol). The uploading functionality works everywhere. So from DevTools LH Panel => get a sharable link is very easy now.
  • we can pipe gist urls through the jsonurl stuff. And that'll let us drop firebase-auth and github-api. (assuming we can get gist content with a single call, no api..)
  • teach the LH Diff Tool to load from these IDs. Then the pattern for getting a comparison URL is really easy.

@paulirish paulirish requested a review from a team as a code owner November 17, 2023 02:23
@paulirish paulirish requested review from connorjclark and removed request for a team November 17, 2023 02:23
@@ -2,7 +2,7 @@
"extends": "../tsconfig-base.json",
"compilerOptions": {
// Limit to base JS and DOM defs.
"lib": ["es2020", "dom", "dom.iterable"],
"lib": ["es2021", "dom", "dom.iterable"],
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

needed for string.replaceAll()

@connorjclark
Copy link
Collaborator

Nice, this is much simpler.

The strings say "permalink", but you mentioned a "365 day TTL". Is this PR currently trading perm-storage for 365 TTL? That seems long enough, but just want to make it clear if that is what's gonna change. If so, calling it "permalink" is not right.

return id;
const updatedUrl = new URL(LighthouseReportViewer.APP_URL);
updatedUrl.searchParams.append('id', id);
history.pushState({}, '', updatedUrl.href);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

wdyt of going even simpler and just making this the jsonurl= to firebase storage URL (then we can drop special handling of ?id. reasons not to:

  1. we like the shorter url
  2. the bucket or path may change

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i like the short url. and i'm excited about https://googlechrome.github.io/lighthouse-ci/difftool/?left=<id>&right=<id> Right now with full urls this gets super long and ugggly

* @param {LH.Result|LH.FlowResult} jsonFile The gist file body.
* @return {Promise<string>} id of the created gist.
*/
async createGist(jsonFile) {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🔥

@paulirish
Copy link
Member Author

The strings say "permalink", but you mentioned a "365 day TTL". Is this PR currently trading perm-storage for 365 TTL?

yes. :)

That seems long enough, but just want to make it clear if that is what's gonna change. If so, calling it "permalink" is not right.

this is fair. i realize now i avoided that term on trace.cafe (for that reason) and went with "shareable URL"

Since we're bikeshedding words.. i feel iffy on "Get".. Do you think Get Shareable URL is fine or should we be more explicit that you send your data to do it, eg... Upload for Shareable URL?

@connorjclark
Copy link
Collaborator

connorjclark commented Nov 17, 2023

Upload/Get doesn't make much difference to me. You can't get a url without putting your data somewhere. shrug.

But, on the point of "your data", with gist you could always delete your data. afaik you can't with trace.cafe. should that be a requirement before we can use trace cafe? butttt now we need auth again, and you'd need to build out login/deleting data, and .... ugh.

So maybe an explicit prompt when you click "get shareable url" that says "your data will be uploaded to trace.cafe and shareable only via this URL for 365 days. Continue?". With that explicit permissions maybe we can curtail needing to provide a way to delete something

@connorjclark
Copy link
Collaborator

connorjclark commented Nov 17, 2023

ID looks like localhost_2021_09_07-70x5q2bg6q3l2mkn4a3oi6m612lo06w63 - so no concern about being able to guess / enumerate all IDs

@paulirish
Copy link
Member Author

But, on the point of "your data"

yeah that's where i was coming at it from... i don't like dealing with the permission prompt and storing that preference etc... so... I just renamed it to 'Upload for Shareable URL' to make that action obvious and explicit.

@brendankenny
Copy link
Member

The user experience seems to be better all around for this (uploading from DevTools is pretty amazing), but as a relatively heavy user of gist uploads, I'll put in a plea for retaining the gist functionality. The biggest thing is probably links working for longer than a year or whatever the TTL ends up settling on. I don't go back through my gists looking for old memories, but I do go back through links from old bugs (year old bugs don't seem as old as they used to), docs, etc and it's definitely nicer when they're still working.

In terms of "your data", I also just generally like the fact that I know where my gists are and how to manage them for things that are meant to be a record of something, vs an ephemeral "hey take a look at this thing" in chat or wherever that trace.cafe is great for.

Since it's an option only visible from the viewer drop down, seems like it could continue living there without adding much confusion about which option to use for getting a shareable link.

@adamraine
Copy link
Member

we can move this feature to the dropdown of all reports (except on file:// protocol)

Why not file://? Seems like a useful way to share reports generated via CLI.

@paulirish
Copy link
Member Author

we can move this feature to the dropdown of all reports (except on file:// protocol)
Why not file://? Seems like a useful way to share reports generated via CLI.

I agree the cli generated reports would really benefit from this feature :)
for some reason i thought you couldn't make http CORS requests from file:// but... i just confirmed they work fine. Okay then nevermind!

@paulirish
Copy link
Member Author

I'll put in a plea for retaining the gist functionality.

@brendankenny want gist uploading functionality? cuz i was gonna keep around downloading. also in that world, you can still upload gists manually at gist.github. wdyt?

@brendankenny
Copy link
Member

@brendankenny want gist uploading functionality? cuz i was gonna keep around downloading.

Yeah, sorry, I meant gist uploading.

also in that world, you can still upload gists manually at gist.github. wdyt?

Well, yes, similar to manually uploading at https://trace.cafe/ :P Having a button makes it very nice :)

: null;
})
.then(() => fetch(jsonurl))
} else if (jsonurl ?? cafeid) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: this is the effective condition so let's make it explicit

Suggested change
} else if (jsonurl ?? cafeid) {
} else if (jsonurl || cafeid) {

finalDisplayedUrl: Util.getFinalDisplayedUrl(reportJson),
fetchTime: reportJson.fetchTime,
});
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can this filename logic move inside uploadLhrToTraceCafe?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants