Gtop100 pingback preview URL shows vote::admin.sites.verifications.key in site editing

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 :

Plugin-Vote/src/Controllers/Admin/SiteController.php

Line 117 in 4529a11

'info' => trans('vote::admin.sites.verifications.key'),

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

    
           'input' => 'The votes on this website will be verified when the input below is filled.',

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

Seems like the cache value stored during pingback is never used, maybe @Javdu10 have an idea why

It is used when the VoteController verify the vote, so it should use it, it might be because user voted directly from gtop100 @Iluay0

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.