Closed shawnlauzon closed 6 years ago
Regarding the "proper" way of verifying:
From my old frontend app, I was just calling again the POST api/create/forum-profile
endpoint (i.e. after calling it once to create the forum profile itself). Calling it again when already exists, will give info about whether or not the signature has been copied and placed in the user's forum profile. This is already documented in the API docs. The status code for the second call is 200
and it should give verified = True
if the signature has been detected in the user's forum profile.
@shawnlauzon On hindsight, this is not very intuitive. I should have separated the call to create the forum profile from verifying the signature placement. I'm not sure now what I was thinking when I wrote this. Anyway, we can keep it like that or change it. I'm not changing anything yet, I'll wait for your go signal.
Regarding the workings of the verification process:
The BB code signature is rendered as HTML in the forum post. What I do is get the rendered HTML and collect the href links. I am checking two things from this links:
vcode
URL param with a string value that is unique for the Venue userThe vcode
is generated by Venue upon forum profile creation and is injected dynamically during retrieval of signature BB code.
The idea behind this vcode
is for us to be able to track the visits to the links when the banner is clicked, which is based on James proposal before that Venue should be able to count the clicks. I thought that since we can't inject Javascript into the signatures, I would add a URL parameter to the links so we can track the visits on the side of the target site (i.e. if we own the target site, not Twitter or FB).
For instance, a link in the banner is https://www.volentix.io
. The link in the rendered HTML signature will actually look something like https://www.volentix.io?vcode=XXX
where XXX is a string code that maps to a specific Venue user. So, in the volentix.io logs we should be able to count how many visits were due to a click on the https://www.volentix.io?vcode=XXX
link. That way, we could measure which signatures are performing well.
To complete the loop, we should somehow implement a system in the volentix.io side that sends a request to Venue to inform it about visits that come from clicks on the signatures in bitcointalk.
Anyway, we can keep it like that or change it. I'm not changing anything yet, I'll wait for your go signal.
This is as I expected. Although not intuitive, there's not a problem with the data structure, and it currently works. So let's keep it for now.
Regarding the workings of the verification process: That's interesting how some user tracking was planned to be done. We don't have anything in plan to do that. @realrhys what do you think about tracking these vcode?
Unfortunately @joemarct I still don't understand what /api/retrieve/signature-code/
does. Since verification seems to be completely covered by '/create/forum-profile`, I don't know what this API calll does. My only guess is that given a vcode, it returns the BBCode, and then as you say it can be used to see what signatures are working. But rather than returning BBCode, wouldn't it make more sense to return the Venue user along with the ID of the signature type which was used?
Regarding this /api/retrieve/signature-code/
endpoint:
There was a specific use case for that in the old frontend. I used to list all the signatures that the user has, listed as images plus a few details. When user clicked on one image, that API endpoint is called (given the vcode as parameter) to retrieve the BB code for that specific signature.
@shawnlauzon My first comment in this issue was incomplete and inaccurate.
The whole process of checking a profile, selecting a signature, placement in the forum profile then verification involves calls to the following API endpoints in this sequence:
GET /api/check/profile
POST /api/create/forum-profile
GET /api/retrieve/signatures/
POST /api/create/signature
I'm explaining it better below with pseudocode:
# Step 1: Checking if a forum user ID exists in the forum site
resp = Call `GET /api/check/profile`
# Step 2: If it exists, create the forum profile for it in Venue
If resp.status_code == 200 and resp.data.position_allowed == true:
resp = Call `POST /api/create/forum-profile`
# Step 3: Retrieve signatures that the user can choose from
if resp.status_code == 201 and resp.data.verified == false:
resp = Call `GET /api/retrieve/signatures/`
Select a signature from the signatures list
# Step 4: Given the ID of the selected signature, check if the signature was copied
resp = Call `POST /api/create/signature`
if resp.status_code == 200:
Verified! Signature was copied and placed in forum profile.
else if resp.status_code == 404:
Signature was not found in the forum profile
Great, thank you that is very clear!
On Thu, Jun 14, 2018, 9:13 AM Joemar Taganna, notifications@github.com wrote:
@shawnlauzon https://github.com/shawnlauzon My first comment in this issue was incomplete and inaccurate.
The whole process of checking a profile, selecting a signature, placement in the forum profile then verification involves calls to the following API endpoints in this sequence:
- GET /api/check/profile
- POST /api/create/forum-profile
- GET /api/retrieve/signatures/
- POST /api/create/signature
I'm explaining it better below with pseudocode:
Step 1: Checking if a forum user ID exists in the forum site
resp = Call
GET /api/check/profile
Step 2: If it exists, create the forum profile for it in Venue
If resp.status_code == 200 and
position_allowed
== true: resp = CallPOST /api/create/forum-profile
# Step 3: Retrieve signatures that the user can choose from
if resp.status_code == 201: resp = Call
GET /api/retrieve/signatures/
Select a signature from the signatures list# Step 4: Given the ID of the selected signature, check if the signature copied resp = Call `POST /api/create/signature` if resp.status_code == 200: Verified! Signature was placed in forum profile. else if resp.status_code == 404: Signature was not found in the forum profile
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Volentix/venue-server/issues/72#issuecomment-397291474, or mute the thread https://github.com/notifications/unsubscribe-auth/AAlUySMWmT75eiFS6ZBQnAmidxK826p2ks5t8mGDgaJpZM4UmMoj .
Need 2 pieces of info: