Gtop100 pingback preview URL shows vote::admin.sites.verifications.key in site editing
Iluay0 opened this issue · comments
Issue
When accessing the page located at /admin/vote/sites/{id}/edit for a Gtop100 entry:
Instead of showing the following text:
- The votes on this site will be automatically verified. Pingback URL: :url
The following text is shown:
- vote::admin.sites.verifications.key
Screenshots
Steps to reproduce
- Add a gtop100.com site.
- Edit the newly added gtop100.com site.
- The text shown underneath the URL should be incorrect, preventing the user from accessing their pingback URL. This is regardless of API Key having a value.
Some additional info
Since I was not sure if this is a bug or a configuration problem, I ended up having a look at the code. To me, this seems to be due to the replacement of the regex key to requireKey('api_key') from the most recent version of the VoteChecker class.
This seems to cause the call to verificationForUrl() to not result in intended behaviour, due to $verifier->requireVerificationKey() now returning true, skipping the pingback behaviour.
I am not knowledgeable with the codebase of Azuriom so I might be wrong on this, though.
Hi, thank you for reporting this! Does it occur only with GTop100 ? Because I cannot test for now, but seems like the translation key in the controller is invalid :
As I guess the correct value should be
input instead of key (but I can’t test right now):Plugin-Vote/resources/lang/en/admin.php
Line 42 in 4529a11
Hello @Iluay0
Can you change the method verificationForUrl to
public function verificationForUrl(Request $request)
{
$voteUrl = $request->query('url');
if ($voteUrl === null) {
return response()->json(['message' => 'Invalid URL'], 422);
}
$checker = app(VoteChecker::class);
$host = $checker->parseHostFromUrl($voteUrl);
if ($host === null) {
return response()->json(['message' => 'Invalid URL'], 422);
}
if (! $checker->hasVerificationForSite($host)) {
return response()->json([
'domain' => $host,
'info' => trans('vote::admin.sites.verifications.disabled'),
'supported' => false,
]);
}
$verifier = $checker->getVerificationForSite($host);
if (! $verifier->requireVerificationKey()) {
return response()->json([
'domain' => $host,
'info' => trans('vote::admin.sites.verifications.auto'),
'supported' => true,
'automatic' => true,
]);
}
$message = trans('vote::admin.sites.verifications.input').' ';
if ($verifier->hasPingback()) {
$message .= trans('vote::admin.sites.verifications.pingback', [
'url' => route('vote.api.sites.pingback', $host),
]);
}
return response()->json([
'domain' => $host,
'info' => $message,
'supported' => true,
'automatic' => false,
'label' => trans('vote::admin.sites.verifications.'.$verifier->verificationTypeKey()),
]);
}To see if it fixes your issue ? thanks
Hi @Javdu10, this does fix the display issue!
However it seems that while the pingback does come back (apache's access logs confirm it), the rewards are not received by the user. Here's an example log (with sensitive data omitted):
172.70.211.20 - - [12/Apr/2023:18:55:02 +0800] "POST /api/vote/pingback/gtop100.com?VoterIP=XXXX&pingUsername=XXXX&Successful=0&Reason=Vote%20accepted&pingbackURL=XXXX&site_id=XXXX&pingbackkey=XXXX HTTP/1.1" 204 - "-" "-"
And here are screenshots of the configuration:
Seems like the cache value stored during pingback is never used, maybe @Javdu10 have an idea why
This is while voting directly from the website.
We do get the pingback request from gtop100 shortly after, with the correct data. The pingUsername specified in the request received matches the username of the account used for voting.
Looking at the requests sent from the vote page (to /vote/site/{id}/done), they all respond with status: "pending". In the data sent, the user field also matches the correct account name.
Attached is a screenshot of what the network tab looks like.
Turns out cloudflare was messing with the pingback, so the only actual issue was the display.