Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
fix(apps/ensadmin): validate name query params on name details page #1834
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
base: main
Are you sure you want to change the base?
Uh oh!
There was an error while loading. Please reload this page.
fix(apps/ensadmin): validate name query params on name details page #1834
Changes from 19 commits
4bf234ff7893a2569f803255190e0a17eea0ab033114e162f72e310e1f29be9a2052941fd70f12ff21a53c05ce3bb498a4077628b3308ed9e92eb03310919af2c039832ac25e8663711456c3e5298885ed1cd779File filter
Filter by extension
Conversations
Uh oh!
There was an error while loading. Please reload this page.
Jump to
Uh oh!
There was an error while loading. Please reload this page.
There are no files selected for viewing
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.
The original issue stated:
and most recently:
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.
I'm aware this is a new file, and not sure where this lives long term.
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.
UnnormalizedNameErroris shown for anynamethat is neither aNormalizedNamenor anInterpretedName, which includes names that are valid and normalizable but simply not normalized (e.g.VITALIK.ETH). In that case, the description "not a valid ENS name" is inaccurate/misleading. Consider distinguishing "valid but not normalized" (e.g.,normalize(name)succeeds but differs) from "invalid" (normalization throws) and adjusting the message accordingly.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.
🧹 Nitpick | 🔵 Trivial
Consider displaying the interpreted name in the error message.
Since
InterpretedNameUnsupportedErroris shown for validInterpretedNamevalues (with encoded labelhashes), you could accept aname: InterpretedNameprop and display it usingformatInterpretedNameForDisplayfor better user context. This aligns with past review feedback suggesting<InterpretedNameUnsupportedError name={...} />.💡 Optional enhancement
🤖 Prompt for AI Agents
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.
This was changed because of the comments made about the downstream handling, and:
NameDetailPageContentonly ever receives a validated normalized name from the detail page check (isNormalizedName(nameFromQuery)), so the prop type was tightened to reflect that guaranteeThere 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.
nameFromQueryis validated without trimming, so URLs like/name?name=vitalik.eth%20(or whitespace-only values) will be treated as invalid and show an error. In this same app, the breadcrumbs page trims the query param before using it. Consider applying.trim()(and treating the empty result as null) before theisNormalizedName/isInterpretedNamechecks.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.
I need to do more work here to clean this up, and move it.
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.
Whitespace-only input is treated as
Empty(no-op) and the submit button is disabled based onrawInputName.trim(). That means an input like " " can't be submitted via the button and won't surface an "Invalid Name" error, which conflicts with issue #1140's acceptance criteria (it explicitly lists " " as an Invalid Name case). Consider disabling only for the truly empty string, and returning an invalid-name outcome (with an inline error) for whitespace-only input.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.
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.
Done, I can remove these TODos now.
Uh oh!
There was an error while loading. Please reload this page.
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.
The detail-page query-param validation currently treats a valid-but-unnormalized name (e.g. "VITALIK.ETH") the same as an invalid name and renders
UnnormalizedNameError(with a "not a valid ENS name" message). This doesn’t match the intended behavior in #1140/#1059, where unnormalized-but-normalizable names should show an explicit "not ENS normalized" error distinct from truly invalid input. Consider adding a separate branch to detect “normalizable but not normalized” (e.g. vianormalize(nameFromQuery)in a try/catch) and render a dedicated error state/message for that case.Uh oh!
There was an error while loading. Please reload this page.
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.
Query parameter validation doesn't distinguish between unnormalized-but-normalizable names and truly invalid names, both showing the same generic "Invalid Name" error
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.
@lightwalker-eth I added
trim()here because I was seeing theView Profilebutton become active, and I think it's better it remains disabled. Empty characters are validated again but the disabled button is only checking for length.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.
@notrab In my mind we make "Empty" a special class of the interpretation outcome and then build logic such as disabling a "View Profile" button based on the "Empty" class of interpretation outcomes.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.