Fix twitter:site links and add opt-in Xquik verification - #337
Fix twitter:site links and add opt-in Xquik verification#337kriptoburak wants to merge 1 commit into
Conversation
✅ Deploy Preview for web-check ready!Built without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify project configuration. |
|
Hey @kriptoburak, I'll take a proper look later on. But just from the description, do you think this could be done without the Xquik service instead? I don't want to incorporate any non-free services, especially if not self-hostable. Also the xquik service seems potentially concerning. Scraping is never good, nor reliable. I'd be concerned about violating the Twitter terms of service too. And given the service is brand new, and doesn't appear very reputable, I don't really want to maintain a whole bunch of code around something which might need to then be ripped out soon. |
|
Thanks for the direct feedback. Your free, self-hostable dependency requirement is incompatible with this integration. I’m closing it instead of asking you to maintain an external service you don’t want. |
| }; | ||
|
|
||
| export const lookupXProfile = async ({ targetUrl, apiKey, get }) => { | ||
| if (!apiKey) return { skipped: 'Xquik profile lookup requires XQUIK_API_KEY to be set' }; |
There was a problem hiding this comment.
We got requireEnv(...) to cover this, re-use from api/_common/upstream.js instead of re-implementing.
There was a problem hiding this comment.
no, we got a really neat job/registry system which all other (client api) checks go through (see src/client/jobs/registry.ts). which handles the threads, signals, parsing, error handling, formatting, etc.
Using a raw fetch without any abort signal will mess up a lot of things.
| 'threats', | ||
| 'tls-labs', | ||
| 'whois', | ||
| 'x-profile', |
There was a problem hiding this comment.
this won't work, since you're not using the job system.
| | `GOOGLE_CLOUD_API_KEY` | A Google API key with the PageSpeed Insights API enabled ([get here](https://developers.google.com/speed/docs/insights/v5/get-started)). This can be used to return quality metrics for a site | | ||
| | `REACT_APP_SHODAN_API_KEY` | A Shodan API key ([get here](https://account.shodan.io/)). This will show associated host names for a given domain | | ||
| | `REACT_APP_WHO_API_KEY` | A WhoAPI key ([get here](https://whoapi.com/)). This will show more comprehensive WhoIs records than the default job | | ||
| | `XQUIK_API_KEY` | An Xquik API key ([get here](https://xquik.com)). This verifies a site's declared X profile after the user confirms the exact handle | |
There was a problem hiding this comment.
like my first comment, this xquick service is the main thing I'm concerned about. We'd probably need to find an alternative way or different (free / open source) service.
This one seems very sketchy. Chances are it'll be dead by end of the year.
What changed
Reproduction
The repository OpenAPI example uses @duckduckgo for twitter:site. The current UI inserts that value unchanged and creates https://x.com/@duckduckgo, which returns an error. The canonical https://x.com/duckduckgo profile loads correctly.
The updated card links the normalized handle. A user can then choose to run one metered Xquik lookup. No lookup runs during an automatic website scan. The server accepts only an exact x.com or twitter.com profile URL, requires the returned username to match, and exposes only bounded public profile fields.
Validation