-
Notifications
You must be signed in to change notification settings - Fork 14k
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
feat: introduce hashids permalink keys #19324
Conversation
Codecov Report
@@ Coverage Diff @@
## master #19324 +/- ##
==========================================
+ Coverage 66.65% 66.67% +0.02%
==========================================
Files 1675 1676 +1
Lines 64654 64687 +33
Branches 6503 6503
==========================================
+ Hits 43092 43127 +35
+ Misses 19876 19874 -2
Partials 1686 1686
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
f5a43e4
to
b6d36d5
Compare
b6d36d5
to
e577500
Compare
@michael-s-molina @ktmud @graceguo-supercat @betodealmeida reviews and comments for the new permalink format would be much appreciated! |
I noticed that when we paste a copied link, it will quickly update the URL with Screen.Recording.2022-03-24.at.11.51.57.AM.mov |
Thank you for the quick iteration and thoughtful implementation. Will take a look later today! |
Haven't looked into the code in details, but based on the PR description, I'm wondering whether we can just generate a new salt and a new uuid for every permalink and save the hashid itself directly in the KeyValue table. We will add a new string column "key" in KeyValueEntry table with index=true, unique=true and nullable=false. When creating a permalink:
When querying a permalink, you just filter the table by the key string. Yes, this will increase the size of the KeyValueEntry table but it should also greatly reduce code complexity. It saves the additional query for getting the shared salt and the need to decode a permalink. |
By saving the key string itself, we also open the possibility for users to configure custom short urls in the future. |
Do you mean regenerate the salt each time? This would open up the theoretical risk of collisions, and would in practice be the same as using
I'm not opposed to introducing a new field in the table, but if it becomes very specific to permalinks, we may be better off with a dedicated table for them.
Again, I may be missing something, but since |
In the case of permalinks, I don't think having the ability to generate "vanity ids" is as useful as for e.g. dashboards (=slugs), as the state contained in permalinks will probably usually tend to go stale over time. |
Indeed, what I described was just a more complex version of |
CreateKeyValueCommand(resource=RESOURCE, value=value, key=uuid_key).run() | ||
|
||
|
||
@memoized |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice
Approving in case you want to merge as is and address @michael-s-molina 's question in another PR. |
Yes, I agree completely - this is a horrible flicker. I would have addressed this here, but it would have required doing a lot of slightly unrelated changes. Since this can be changed later, I'd prefer to get this PR merged first and happy to add more polish to this once it's done. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thanks for the improvement!
Thanks for the reviews! I'm going to merge as is, and like I said, happy to keep improving this and related features! |
* feat: introduce hashids permalink keys * implement dashboard permalinks * remove shorturl notice from UPDATING.md * lint * fix test * introduce KeyValueResource * make filterState optional * fix test * fix resource names (cherry picked from commit f4b71ab)
* feat: introduce hashids permalink keys * implement dashboard permalinks * remove shorturl notice from UPDATING.md * lint * fix test * introduce KeyValueResource * make filterState optional * fix test * fix resource names
SUMMARY
This PR implements
hashids
based permalinks on both Dashboard and Explore, and deprecates the currently supported integer and UUID based permalinks that were introduced here: #19078.Old UUID format (default):
https://host/dashboard/p/035ed596-546d-4563-a482-02d5dd4649d8/
Old numeric format (optional):
https://host/dashboard/p/1/
New format:
https://host/dashboard/p/dVK7AbavkPy/
The motivation for this change is this discussion. TL;DR:
hashids
provide shorter and less hideous permalinks thanks to being base62 (vs UUID which uses a regular base16 hex alphabet) and obfuscate numeric ids in a way that makes it infeasibly difficult to guess the actual id.When creating a permalink for the first time, the app checks if a "salt" has been created for the resource in question (separate for Dashboard and Explore): if not, it creates a 48 character string using
secrets.token_urlsafe
(similar to how the temporary cache keys are currently constructed) and persists it in the key-value store under the "app" resource. By automatically generating the salt we avoid the need for introducing new config parameters. By creating separate salts for Dashboard and Explore we ensure thatUsing
SECRET_KEY
was not possible for the following reasons:SECRET_KEY
would have required rotating all permalink keys, which is impossible, as they're "out in the wild"hashids
compromising the salt, theSECRET_KEY
could be exposedThe minimum length of the hashids key is set at 11 characters: this was mostly an arbitrary decision. However, here's a few reasons that support using 11 chars:
Note that this will invalidate permalinks created on deployments that have been running with this cherry: #19078. However, since this PR is fairly recent and hasn't been released in an official Apache release, the risk is minimal that this would have been in production use anywhere. Needless to say, this cherry will be included in the forthcoming 1.5.0 version.
BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
TESTING INSTRUCTIONS
ADDITIONAL INFORMATION