-
-
Notifications
You must be signed in to change notification settings - Fork 7k
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
Redesign forms, verify link ownership with rel="me" #8703
Conversation
dbb3406
to
c5654bc
Compare
A TXT record for alternative verification would be nice. For example I wouldn't like having to add a link to my profile on the index of my GitLab instance and stuff like that. Verifying multiple profiles is already possible with the current method. There should also be a way to confirm one link with multiple accounts using DNS. (comma separated links?) |
The complexity with doing DNS verification comes from the fact that each link needs a special verification string, so the field must be saved before that string can be given to the user for copypasting, which means the actual verification must be done in a yet another step (+ wait for DNS propagation) Don't forget that each server must verify on its own. I don't see how the user could have any control over when the checks happen, currently it's just tied into when the profile has been updated. |
DNS verification could work in a similar fashion, listing domain or URLs to be honest. Although we probably want to check what kind of standards or proposed standards there already are for this. Another minor issue I have with this is that this requires you to basically advertise your other identities everywhere, while someone may want to have only one-way verification (e.g., I may have a “private account” that I don't want to advertise to other people, but that I want to verify as being the private account tied to my public account). Finally, I would also extend this to |
I think this is a pretty good solution! Not complicated UI-wise, and doesn't require the user's browser to do the validation work. |
@Gargron: how does the link verification get triggered? |
"ownership of this link was checked..." might be better as:
with the negative case being:
Alternatively, no messaging on unverified links might also be better, so that no negative connotations are applied to links that are not intended or desired to be verified. Perhaps a checkbox representing "this is me, please verify" ("I own this site" ?) to signify verifiable links? could also cut down on effort verifying non-verifiable links. I'm still not sure what I think about using "verification" language in this feature, given the baggage it carries from birdsite, but it is terminology that users understand. |
app/services/verify_link_service.rb
Outdated
def link_back_present? | ||
return false if @body.empty? | ||
|
||
Nokogiri::HTML(@body).xpath('//link[@rel="me"]').any? { |link| link['href'] == @link_back } |
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.
Shouldn't the XPath read //link[@rel="me"]|//a[@rel="me"]
? The copy you've written mentions <a rel="me"
but this won't match that.
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.
My bad, it should be a
instead of link
, not sure if link
is worth checking at all, that would be a real rarity
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.
True, both link
and a
are valid for rel=me
.
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 initially thought it was a “link” attribute and not a “a” attribute. Can't find the spec (if any) right now, but if link's in it, you should restore it, even if it “would be a real rarity”.
@ThibG Okay, both anchor and link tags will be checked. |
* Fix performance regression in Account::Field#verifiable? Regression from #8703 * Fix code style issue
UX-wise, people expect that saving the profile will re-check links even without changing fields content. Bug-wise, `@account` was undefined. Regression from #8703
UX-wise, people expect that saving the profile will re-check links even without changing fields content. Bug-wise, `@account` was undefined. Regression from #8703
* Verify link ownership with rel="me" * Add explanation about verification to UI * Perform link verifications * Add click-to-copy widget for verification HTML * Redesign edit profile page * Redesign forms * Improve responsive design of settings pages * Restore landing page sign-up form * Fix typo * Support <link> tags, add spec * Fix links not being verified on first discovery and passive updates
* Fix performance regression in Account::Field#verifiable? Regression from mastodon#8703 * Fix code style issue
UX-wise, people expect that saving the profile will re-check links even without changing fields content. Bug-wise, `@account` was undefined. Regression from mastodon#8703
* Verify link ownership with rel="me" * Add explanation about verification to UI * Perform link verifications * Add click-to-copy widget for verification HTML * Redesign edit profile page * Redesign forms * Improve responsive design of settings pages * Restore landing page sign-up form * Fix typo * Support <link> tags, add spec * Fix links not being verified on first discovery and passive updates
* Fix performance regression in Account::Field#verifiable? Regression from mastodon#8703 * Fix code style issue
UX-wise, people expect that saving the profile will re-check links even without changing fields content. Bug-wise, `@account` was undefined. Regression from mastodon#8703
How long should we expect the ownership verification to take effect? |
Ok, so I deleted my link, saved, re-added it and re-saved and the green highlighting appeared instantly. |
I think it would be a good idea to add a 2-hop check? Use case? I've encountered this issue with EteSync. Relevant links to see what I'm talking about: |
@tasn I suggest opening a separate feature request for this! |
Done. #11391 Sorry for the noise. |
Conflicts: Gemfile Gemfile.lock app/javascript/mastodon/features/compose/index.js app/serializers/initial_state_serializer.rb app/views/about/_registration.html.haml app/views/admin/settings/edit.html.haml app/views/auth/registrations/edit.html.haml app/views/shared/_og.html.haml config/initializers/omniauth.rb package.json Look at f6df9d0 . The diff is too difficult to read however, in file app/views/auth/registrations/edit.html.haml, `simple_form.labels.defaults.password` was suddenly replaced to `simple_form.labels.defaults.new_password`. This can be proved by this file on ef27a0b which is a parent commit of that. However, this replacement has been continued for about 3 years. And there is no significant difference. So, I decided not to recover this replacement. ref: - 1cd0497 - increments#8 - f4d549d - mastodon#8703
Summary:
rel="me"
References:
To some extent:
Verified links:
Forms redesign: