Using/ Calling Default 'Email Verification' template and using SMTP settings setup in Admin Dashboard?

[hqnsel]

I am self-hosting PB on digitalocean's droplet, and I've setup the custom action URL, modified the default mail templates, and also setup my SMTP server settings.

However, I wish to use my go backend to call these methods (basically to connect via pocketbase.NewClient with my admin credentials before calling required methods) , but I can't seem to find the correct method for this. Do I follow

https://pocketbase.io/docs/sending-emails/#overwrite-system-emails or use event hooks?

I

[ganigeorgiev]

I'm not sure that I understand the question.

Are you using PocketBase as framework OR interacting with PocketBase from another Go application using the unofficial go client sdk (because we don't have pocketbase.NewClient method)?

The docs link in your post works only if you use PocketBase as framewok.

If you are interacting with PocketBase from external application via the web APIs, then you can check https://pocketbase.io/docs/api-records/#auth-record-actions and the "Request verification" call (but I'm not sure if this method is supported by the unofficial go client).

[hqnsel]

Thank you, and yes I meant ' interacting with PocketBase from external application via the web APIs'. Thank you for pointing me to the right direction. I managed to resolve it by using a direct http request with admin token instead.

I would like to seek your knowledge on two points:

1. Currently, when a user receives the email verification, and clicks on 'Verify' multiple times, it sends multiple

POST /api/collections/pb_users_auth/confirm-verification to my pocketbase server. How do i manage it such that it works to only allow 'Verify' once - after that when users presses on it it does not send POST to my api server?

2. the 'Invalidate all previously issued tokens' option under each Record/Admin token settings in token options tab, is it meant as a 'Reset Button', where once pressed all previously issued tokens are rendered invalid, or is it meant as a "when the next token is issued, the previous token is invalid"?

I am asking because I am planning on using admin tokens as a variable for my new users to send out requestverifications, and i wish to render each token invalid upon confirmation of email verification. I guess I won't really have a need for the 'Invalidate all previously issued tokens' option, but was just curious.

[hqnsel]

(https://ibb.co/1RZvQ2r) I just tried again, when pressing on 'Verify' button multiple times, the above is what I get. and each time, the redirect link shows "Successfully verified email address." I think I am doing something wrong here..

[ganigeorgiev]

I cannot open the above url. See the note about the possibility for a race in the above comment, but again it shouldn't really matter.

I'll consider with the next release to enforce the invalidation of previously issued verification tokens once a single token is confirmed instead of just silently ignoring/skipping the verified field update. On second thought, this actually may not be possible per user since it will invalidate also the auth user tokens (if there is any). Again, technically it shouldn't really matter; we return always a 204 success if the user is already verified.

[hqnsel]

my main concern is that multiple 'POST' are being called which might result in spam or unwarranted number of requests being made, not so much of the user receiving the email multiple times (they only received it once), more on them clicking on 'Verify' and making multiple repeated requests. Thank you for your patience!

[ganigeorgiev]

my main concern is that multiple 'POST' are being called which might result in spam or unwarranted number of requests being made,

Users can always send requests to your server and responding with an error is no different then a success response, aka. at the end the request already reached the server.

Users can spam your server by just sending request to the health api. If you are concerned about DDoS, then this needs to be handled on a different level (ideally before even reaching your server).

[hqnsel]

alright - i understand, thank you!