gs-odrs-provider: Fix voting and reporting reviews

This is almost entirely based on an investigation by Milan Crha, who deserves the credit for this fix: #1010 (comment 1405055).

The user_skey returned by the server when calling fetch is a hash of the client-provided user_hash and the app_id of an app. In order to vote for or report a review, the user_skey which was returned by the server for that review has to be re-sent to the server by the client, along with the app_id and user_hash.

Due to the use of compat_ids to link together reviews from multiple IDs for the same app (for example, org.gnome.Weather, org.gnome.Weather.desktop and org.gnome.Weather.Application.desktop), different reviews for the same app may have different associated app_ids.

You’d think that the user_skey to be sent to the server to vote for a given review should be a hash of the app_id associated with that review, but it’s not. It’s actually a hash of the app_id originally used to request the reviews from the fetch endpoint.

So use that app ID, rather than the one listed against the review.

An alternate server-side fix is Infrastructure/odrs-web!15 (merged), but this change will break that one.

Signed-off-by: Philip Withnall pwithnall@endlessos.org

Fixes: #1010 (closed)

Closes #1010 (closed)